Küsimus:
Kui mitu sama veebisaidi kasutajat kasutavad sama parooli, kas nende parooli räsi on sama?
Just
2016-02-25 08:58:21 UTC
view on stackexchange narkive permalink

Minu põhiteadmised eeldaksid jah, välja arvatud juhul, kui veebisaidid kuidagi lisavad kasutajanime parooliga räsimisfunktsiooni, kuid ma pole kindel, kas see on levinud tava.

Ainult siis, kui sait on olnud oma turvalisuse suhtes ohtlikult hooletu ja ei kasuta juhuslikke sooli. Sel juhul on teil suuremaid probleeme.
Seotud: [Miks on soolatud räsid paroolide salvestamiseks turvalisemad?] (Http://security.stackexchange.com/q/51959/29865)
Nõustun duplikaatettepanekuga. Las ma kirjutan siiski natuke nende kahe ühendamiseks. On väga ebatõenäoline, et kõik saidid on valinud sama räsimisfunktsiooni ja kasutavad räsimisfunktsiooni täpselt sama rakendust (nagu öeldakse, arendajad armastavad ratast uuesti leiutada). Isegi kui nad kasutavad täpselt sama rakendust, on * sool * oma olemuselt juhuslik teave. See juhuslikkus tagab, et kõik räsid peaksid saitidel olema erinevad.
Kaks vastused:
iAdjunct
2016-02-25 09:11:50 UTC
view on stackexchange narkive permalink

See sõltub sellest, kas nad lisavad üksikuid sooli või mitte või kasutavad tavalist soola (või üldse mitte).

Kui nad kasutavad üksikuid sooli, siis on need erinevad; muidu on nad [tõenäoliselt] samad.

Ma arvan, et kas ma mõtlesin, et kas see on tööstusstandard?
See peaks olema ja siis, kui küsida kelleltki, kes teab, millest ta räägib. Kuid kurb tõde on see, et paljud veebisaidid ei järgi seda "standardit" ... muutes selle vähem standardiks ja pigem "võlgu jumalat, ma loodan, et inimesed seda teevad"
@Nanne Ma arvan, et peaksite selgitama, millega olete seotud, kui räägite tavapärasest tavast. OP võib segaduses olla, kas viidate sellele vastusele või tema küsimusele. Minu kogemuse kohaselt on "soolatud" paroolid unikaalsete sooladega (nt kasutajate e-posti aadress), nii et iga kasutaja parooli räsi on erinev ja ainulaadne
Püüdsin öelda, et sellised sõnad nagu "tööstuse standard" ja "levinud tava" on rasked. Soola tegemine on "parim tava", kuid kurb tõsiasi on see, et see pole iseenesest kõige sagedamini kasutatav tava, sest seal on palju sh * t. Nii et võib-olla pole mu inglise keel eriti hea, kuid üritasin vihjata, et kuigi miski on „standard”, ei tähenda see, et seda niimoodi tehakse. Igal juhul oli minu vastus kommentaarile, kus küsiti, kas soolamine on tööstusharu standard
Anti-weakpasswords
2016-02-25 10:07:23 UTC
view on stackexchange narkive permalink

Nagu alati, on hea lugemine Thomas Pornini kanooniline vastus teemale Kuidas paroole turvaliselt räsida, mis annab nii nõuandeid kui ka selgitusi ainulaadsete kasutajate krüptograafiliselt juhuslike soolade kohta koos PBKDF2, BCrypt ja SCrypt olles valitud algoritmid ja nimetatud soolad on kohustuslikud.

Oma konkreetse küsimuse jaoks lugege lihtsalt läbi paroolidega sildiga security.stackexchange.com ja stackoverflow.com küsimused ning leiate kiiresti, et need on seal ei ole tavaline viis paroolidega midagi teha.

SCrypt on peaaegu tundmatu.

BCrypt on enamasti reserveeritud PHP 5.5 ja uuemate versioonide jaoks (ja 5.3.7 parooliga_compat; on palju / PHP inimestest, kes seda kasutavad, ja suur hulk PHP inimesi, kes kasutavad midagi muud.

PBKDF2 on hea valik peaaegu kõigile teistele.

Ja teil on ikka veel kombinatsioon teistest kordustest räsimeetodid (sageli soolamisvigadega), räsi üksikud kordused (tavaliselt soolamisvigadega), soolamata räsid ning välja ja välja Ärge olge a Dave küsimusi, ikka ja jälle, veel ja veel ja veel.

Nii et ei; paroolide käsitlemisel peaksite eeldama, et Dave kodeerib teie veebisaiti.

PHP puhul soovitatakse Bcryptit üle Scrypt (http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html). Ja kui inimesed kasutavad PHP-d, peaksid nad ikkagi kasutama vähemalt 5,5. Selle taga pole tegelikult põhjust olla. Ruby on Railsile näib, et Bcrypt on lemmik. Ja tore asi Bcryptis on see, et see teeb soola automaatselt.
BCrypt on standardvarustuses ka Spring Security (Java) versiooniga: http://docs.spring.io/spring-security/site/docs/current/apidocs/org/springframework/security/crypto/bcrypt/BCryptPasswordEncoder.html
@Micheal - alates sellest kuust on vähemalt üks hostimise pakkuja, kes toetab ainult 5.3.3. Olen näinud mitmeid PHP küsimusi paroolide kohta, kus neid ei olnud isegi versioonis 5.3.7, seega polnud lubatud isegi password_compat. Olen nõus, et nad PEAKSID olema millegi muu kui uuema kallal, kuid masendav fakt on see, et nad pole seda.


ⓘ
See küsimus ja vastus tõlgiti automaatselt inglise keelest.Algne sisu on saadaval stackexchange-is, mida täname cc by-sa 3.0-litsentsi eest, mille all seda levitatakse.
Loading...