Kysymys:
Jos useat saman verkkosivuston käyttäjät käyttävät samaa salasanaa, onko heidän salasanansa hajautus sama?
Just
2016-02-25 08:58:21 UTC
view on stackexchange narkive permalink

Perustietoni olettaa kyllä, ellei verkkosivustot sisällä jotenkin käyttäjänimeä salasanan kanssa hajautusfunktiossa, mutta en ole varma, onko tämä yleinen käytäntö.

Ei, ellei sivusto ole ollut vaarallisesti huolimaton heidän turvallisuudessaan eikä käytä satunnaisia ​​suoloja. Siinä tapauksessa sinulla on suurempia ongelmia.
Aiheeseen liittyvä: [Miksi suolatut hashit ovat turvallisempia salasanan tallentamista varten?] (Http://security.stackexchange.com/q/51959/29865)
Olen samaa mieltä ehdotuksen kanssa. Saanen kuitenkin kirjoittaa vähän yhdistääksesi nämä kaksi. On erittäin epätodennäköistä, että kaikki sivustot ovat valinneet saman hajautusfunktion ja käyttävät täsmälleen samaa hajautusfunktion toteutusta (kuten sanotaan, kehittäjät rakastavat pyörän keksimistä uudelleen). Vaikka he käyttävät täsmälleen samaa toteutusta, * suola * on luonteeltaan satunnainen tieto. Tämä satunnaisuus varmistaa, että kaikkien hajautusten tulisi olla erilaisia ​​sivustojen välillä.
Kaksi vastused:
iAdjunct
2016-02-25 09:11:50 UTC
view on stackexchange narkive permalink

Se riippuu siitä, lisätäänkö ne yksittäisiä suoloja vai eivätkö ne tavallista suolaa (vai ei lainkaan).

Jos he käyttävät yksittäisiä suoloja, ne ovat erilaisia; muuten he [todennäköisesti] ovat samat.

Luulen, että mietin, onko tämä käytäntö alan standardi?
Sen pitäisi olla, ja se on, jos kysyt keneltä tahansa, joka tietää, mistä he puhuvat. Mutta surullinen totuus on, että monet verkkosivustot eivät noudata tätä "standardia" ... mikä tekee siitä vähemmän standardin ja enemmän "ow god toivon, että ihmiset tekevät tämän"
@Nanne Mielestäni sinun pitäisi selventää, mihin olet yhteydessä, kun puhut yleisestä käytännöstä. OP voi olla hämmentynyt siitä, viittaatko tähän vastaukseen vai hänen kysymykseensä. Kokemukseni mukaan yleinen käytäntö on "suolata" salasanasi ainutlaatuisilla suoloilla (esim. Käyttäjien sähköpostiosoitteilla) tällä tavalla jokaisen käyttäjän salasanan tiiviste on erilainen ja ainutlaatuinen
Yritin sanoa, että sanat, kuten "alan standardi" ja "yleinen käytäntö", ovat vaikeita. On "parasta käytäntöä" tehdä suola, mutta surullinen tosiasia on, että se ei sinänsä ole eniten käytetty käytäntö, koska siellä on paljon sh * t. Joten siellä, ehkä englannini ei ole kovin hyvä, mutta yritin antaa ymmärtää, että vaikka jokin on 'standardi', se ei tarkoita, että se tehdään tällä tavalla. Joka tapauksessa vastaukseni oli vastaus kommenttiin, jossa kysyttiin, onko suolaus teollisuuden standardi
Anti-weakpasswords
2016-02-25 10:07:23 UTC
view on stackexchange narkive permalink

Kuten aina, hyvä lukema on Thomas Porninin kanoninen vastaus salasanojen turvalliseen hajauttamiseen, joka antaa sekä neuvoja että selityksiä yksilöllisistä salausteknisesti satunnaisista käyttäjäkohtaisista suoloista PBKDF2: n, BCryptin ja SCryptin kanssa. ovat valitsemiasi algoritmeja ja mainitut suolat ovat pakollisia.

Lukeaksesi kysymyksesi, lue vain salasanat-tunnisteella security.stackexchange.com- ja stackoverflow.com-kysymykset, ja huomaat sen nopeasti siellä ei ole tavanomainen tapa tehdä mitään salasanoilla.

SCrypt on melkein tuntematon.

BCrypt on varattu enimmäkseen PHP 5.5: lle ja uudemmille (ja 5.3.7 salasanan_yhteensopivilla; siellä on hyvä määrä PHP-käyttäjistä, jotka käyttävät sitä, ja suuri määrä PHP-ihmisiä, jotka käyttävät jotain muuta.

PBKDF2 on hyvä valinta melkein kaikille muille.

Ja sinulla on vielä yhdistelmä muita iteroituja hash-menetelmät (usein suolausvirheillä), yksittäiset hash-iteraatiot (yleensä suolausvirheillä), suolattomat hashit ja ulos ja ulos Älä ole a Dave -kysymyksiä, yhä uudelleen ja uudestaan ​​ja uudestaan ​​ja uudestaan.

Joten ei; kun on kyse salasanojen tosiasiallisesta käsittelystä, sinun on oletettava, että Dave koodaa verkkosivustoasi.

PHP: n tapauksessa Bcryptia suositellaan Scryptin kautta (http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html). Ja jos ihmiset käyttävät PHP: tä, heidän pitäisi todellakin käyttää ainakin 5.5. Ei todellakaan ole syytä olla niin takana. Ruby on Railsille Bcrypt näyttää olevan suosikki. Ja Bcryptin mukava asia on, että se tekee suolan automaattisesti.
BCrypt on myös vakio Spring Securityn (Java) kanssa: http://docs.spring.io/spring-security/site/docs/current/apidocs/org/springframework/security/crypto/bcrypt/BCryptPasswordEncoder.html
@Micheal - tässä kuussa on ainakin yksi palveluntarjoaja, joka tukee vain 5.3.3: ta. Olen nähnyt useita PHP-kysymyksiä salasanoista, joissa ne eivät olleet edes 5.3.7: ssä, joten edes password_compat ei sallittu. Olen samaa mieltä siitä, että heidän PITÄÄ olla jossakin muussa kuin uudessa, mutta masentava tosiasia ei ole.


ⓘ
Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...