Newsgroup: it.lavoro.professioni.webmaster
Titolo: aruba salva le password in chiaro!!!

Oggi non ricordavo più la password per gestire la mia casella pec, ho 
chiesto un promemoria e al mio indirizzo di registrazione mi è arrivato 
un messaggio con username e password in chiaro!!!


non necessariamente, potrebbero usare un sistema di criptazione a 2 vie, in modo che le possano decriptare usando una chiave salvata da qualche parte per spedirle a chi se le dimentica; ma allo stesso tempo tenendole criptate nello storage

 non necessariamente, potrebbero usare un sistema di criptazione a 2 vie, in modo che le possano decriptare usando una chiave salvata da qualche parte per spedirle a chi se le dimentica; ma allo stesso tempo tenendole criptate nello storage
 
come no, e gli asini volano
http://www.troyhunt.com/2012/07/lessons-in-website-security-anti.html
 
 
 

 come no, e gli asini volano
 
"With sufficient thrust, pigs fly just fine."
 
-- 
Andrea
 

On 17/10/13 11.15, Jeff ha scritto:

LOL
dubito che Aruba operi in modo così complesso :)
 
Gabriele
 

non necessariamente, potrebbero usare un sistema di criptazione a 2 vie
 
Si', ma appunto: un sistema di criptazione e' invertibile, e soprattutto la
chiave DEVE ESSERE ACCESSIBILE AL SERVER (quindi, compromesso quello, l'hai
preso darètri come il giorno del castigo). Un hash non e' invertibile.
 
Quindi, e' comunque piu' sicuro l'hash.
 
Quanto poi a mandare la password della PEC in chiaro su SMTP+POP3, abbeh.
 
Leonardo
 
-- 
 
Then felt I like some watcher of the skies, when a new planet swims into his ken;
Or like stout Cortez when with eagle eyes, he star'd at the Pacific; and all his men
Look'd at each other with a wild surmise - silent, upon a peak in Darien.

 criptate nello storage
 
Oppure (piů semplicemente) č la password generata in fase di creazione della 
pec e quindi non č necessariamente quella giusta (il mio gestore fa cosě: ti 
puň rimandare la prima oppue la ricrea ex novo)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 


Sinceramente dubito anche io, ma il mio punto era che senza conoscere il sistema non ha senso tirare conclusioni.
 
Oppure hanno pensato: "Tanto se ci bucano ci fregano tutto comunque (e questo succede in continuazione anche alle aziende IT piu' fighe del pianeta), quindi chisse ne frega"
 
 
La conclusione dell'OP e' sbagliata, o cmq imprecisa, la conclusione dovrebbe essere: Aruba mi manda la pass in chiaro, che le salvi in chiaro nello storage?
 
E poi se l'OP ha dimenticato la password come puo' essere sicuro che la nuova password sia la vecchia? :O
 
J
 


Non c'è niente di cui scandalizzarsi se le password vengono salvate in 
chiaro.
 
Qualunque database non banale ha informazioni ben più sensibili delle 
password e quand'anche venisse bucato il problema peggiore è aver avuto 
accesso a quei dati, non alle password.
 
Una cosa ben più criticabile è che le password in chiaro *le mandino via 
mail*!
 
Detto questo, qualcuno ha da consigliare una buona implementazione di SRP in 
Javascript che sia compatibile con l'implementazione ruby 
https://github.com/lamikae/srp-rb
 o un'altra equivalente?
 
Ciao,

 accesso a quei dati, non alle password.
 
scusa ma hai voglia di scherzare? sta parlando della casella postale, 
anzi della pec la cui ownership è certificata. la password non è un "dato 
sensibile", rappresenta le credenziali che attribuiscono una identità per 
un dato servizio. se qualcuno fotte la password il problema non è a quali 
altri dati può aver avuto accesso, ma tutto quello che potrà fare a 
seguito del furto di identità...

 altri dati può aver avuto accesso
 
Non penserai mica che un siffatto database abbia solo dati anagrafici e 
password...
 
 

 password...
 
pur ipotizzando il massimo della cialtroneria mi verrebbe da dire di sì, 
al massimo mi aspetterei di trovare le credenziali insieme all'anagrafica 
dell'utente. 
 
in ogni caso posso ragionevolmente pensare che sul siffatto database non 
ci sia la mia posta, ad esempio. di sicuro non c'è quella che mi deve 
ancora arrivare e che da quel momento in poi chiunque potrà leggere, a 
mia insaputa, con un client pop3/imap. e di sicuro non ci sarà la massa 
di informazioni (il cui limite è solo la fantasia) a cui un 
malintenzionato può accedere sostituendosi a me nell'uso di una casella 
postale.
 

 postale.
 
Se hai accesso a quel database, al quale, presumibilmente, è collegato il 
provisioning, pigli, cambi la password, scarichi la casella e poi rimetti la 
password originale.
 
Gli scenari di escalation sono infiniti....

 rimetti la password originale.
 
eeh, troppa trama. se la password è registrata in chiaro non ha alcun 
bisogno di cambiarla; gli basta guadagnare l'accesso in sola lettura, 
tirare giù tutto il db e poi con calma visitare tutti gli account.
 

 accesso a quei dati, non alle password.
 
Ah, non sapevo fosse stata totalmente riscritta la teoria sulla 
sicurezza nel web.
Da ora in avanti lascerò sempre le chiavi nel quadro dell'auto, tanto se 
me la rubano possono lo stesso compiere degli atti gravissimi, il fatto 
che mi rubino le chiavi deve essere l'ultimo dei miei pensieri.
 


https://github.com/lamikae/srp-rb
 o un'altra equivalente?
 
JSCrypto cos'ha che non va? (Do per scontato che tu l'abbia provata)... non
so niente dell'implementazione ruby.


 non so niente dell'implementazione ruby.
 
A questa non ci crede *nessuno*! Non mi dire che non hai mai pensato
cose sconce di una diciassettenne anche non nipote di Mubarak... :-P
-- 
Lex Tutor
L'Asilo Infantile di Bofhland� � un argomento che sar� oggetto
di un libro di prossima pubblicazione, quindi sto discutendo
di una questione che mi interessa per finalit� di ricerca

 cose sconce di una diciassettenne anche non nipote di Mubarak... :-P
 
Si': pero', quando l'ho fatto avro' avuto diciott'anni.
 
Parra' incredibile ai piu' [1], ma del cd. 'Caso Ruby' me n'e' sempre
importato zero, e la Ruby in questione manco so che faccia abbia - o,
se e' per quello, che culo [2].
 
Per me, 'Ruby' e' qualcosa che va *sui* binari, non *accanto* :-D
 
Leonardo
 
[1] cosa non si fa, per liberarsi di un Chissenefrega del 2007 ormai
    prossimo alla data di scadenza
[2] alcuni mi dicono che vi sia poca differenza, altri che sia tutt'
    altra cosa


 Da ora in avanti lascerò sempre le chiavi nel quadro dell'auto
 
L'analogia è fallace. Devo spiegarti perché?
 

 (Do per scontato che tu l'abbia provata)...
 
Sì, ma non in questo ambito.
 
Ciao,

 tirare giù tutto il db e poi con calma visitare tutti gli account.
 
Per inciso, sono d'accordo con te che sia Cosa Buona e Giusta® e sono io il 
primo a premurarmene ci tenevo solo a sottolineare che in prospettiva ci 
sono ben altri problemi per cui strapparsi i capelli...
 
Avere un meccanismo two-way non è tanto meglio di avere le password in 
chiaro ma ci possono essere motivi validi per non usare un meccanismo one-
way.

 chiaro (non per niente si chiama *shared* secret).
 
ma in un meccanismo challenge-response la shared secret *non* è ciò che è 
necessario e sufficiente all'utente per fare la login, come nel caso in 
questione. cioè se io uso 'pippo' per fare la login e leggere la posta 
'pippo' *non* è una shared secret e quello non è, ovviamente, un 
meccanismo challenge-response.
 

 questione
 
Uh? Non ho compreso cosa intendevi.
 
Sto dicendo che, magheggi a parte, per usare CHAP, CRAM-MD5 e simili devi 
essere in possesso della password in chiaro da entrambi i lati.
 
Ciao,

Certo che poi se l'applicazione client-side è servita dallo stesso server...
 
Mettere tutte le uova nello stesso cesto non e' mai stata una politica
lungimirante.
 
C'e' da dire che a volte ce l'hai di requisito, e li' sei vittima :-(
