RIM, BlackBerry alla riscossa

Re: Ma perche' le salvano in chiaro?
- Scritto da: underpaid_d eveloper
Concordo in pieno.
Si potrebbe anche discutere sul fatto che
l'utente medio si ostini ad usare password come
123456!!!L'utente medio puo' usare la password che gli pare: i sistemi per difendersi da un brute force attack ci sono.Ma se uno adotta una password anti brute force, ma il server la salva in chiaro e poi si fa bucare, come ti difendi?

Re: Ma perche' le salvano in chiaro?
- Scritto da: daniele_dll _rosica
mmm, il problema non erano le password in chiaro
o meno ma che venivano scritte nei log (il nome
utente ci sta, ma la
password?!?!?!)Venivano scritte nei log IN CHIARO!!!!Pure io ho delle applicazioni che richiedono autenticazione e scrivono nei log la password, ma gia criptata, cribbio!
comunque il discorso password va preso con le
pinze:
- se ti serve avere le password non reversibili
vai con un hash o un hmac-hash e sei
tranquillo;
- se ti serve la password reversibile allora la
situazione è differente perché visto che il
sistema informatico deve essere in grado di avere
l'originale per operare sei punto accapo ...Quando mai serve una password non reversibile?Il proXXXXX di criptazione della password e' sempre non reversibile.Scrivi la password 12345Il sistema immediatamente la cripta con un hash non reversibile ahr34gres34e questo viene scritto nel log, e questo viene salvato su disco.Quando ti autentichi, il sistema cripta quello che scrivi e lo confronta col criptato. Se sono uguali, bene, altrimenti password errata.Gli algoritmi di hashing non reversibile sono presenti in tutte le librerie, e se proprio non li hai, prendi due numeri primi grossi, e te ne scrivi uno.
certo eviti che il ragazzino ottenga in chiaro le
credenziali di acXXXXX, ma una volta che il
sistema viene bucato a fare un bel tar della root
(escludendo dev, proc, sys, tmp, var/tmp, var/run
e via dicendo) e scaricarselo non ci vuole poi
molto
:)E otterresti un bel file con gli hash invece delle password in chiaro, dei quali non ti fai niente perche' la criptazione e' irreversibile.
PS: mi sembra chiaro che in un contesto la
cifratura rsa non serve visto che la chiave
necessaria alla decodifica dovrebbe comunque
essere presente sul server visto che serve in
chiaro a luiNon e' mica scritta in chiaro la chiave di codifica.
PPS: per "servire in chiaro la password" intendo
che possibilmente il software magari opera in un
contesto in cui deve comunicare le credenziali ad
un servizio esterno (verso un server interno o
verso un altro server esterno alla rete) e quindi
non si può fare molto (dipende dal sistema a cui
si comunicano le credenziali ... Le password devono viaggiare criptate, se vuoi fare le cose fatte bene.Altrimenti c'e' sempre l'alternativa di fare le cose col XXXX, e poi siamo qui a piangere perche' qualcuno penetrando per sbaglio, trova migliaia di password in chiaro.
ovviamente ci
sono sempre delle possibilità ma se il sistema
esterno non è adatto c'è poco che
fare)Esistono policy di sicurezza che vanno rispettate.Se una procedura non rientra nelle policy di sicurezza aziendali, si va dal project manager e gli si spiega il problema.Ovviamente il sistemista bravo, solleva tale eventuale problema il giorno zero dell'analisi di progetto.Quello meno bravo lo solleva quando se ne rende conto (a.k.a. troppo tardi) e a quel punto la frittata e' fatta.
PPPS: in questo caso è negligenza pura e basta :)Sommata ad una buona dose di inesperienza/idiozia.