Küsimus:
Paroolide räsimine peaks md5-d käima tuhandeid kordi: tõesti?
user5575
2012-06-17 05:38:52 UTC
view on stackexchange narkive permalink

Ma vaatasin läbi kuidas ettevõtted saavad parooliturvalisust parandada ja arvasin, et mitmed väited olid täiesti valed, eriti:

  1. krüptograafiline räsi (nt md5) sool on halb.
  2. Pole haruldane, et unix-varifaile lõhutakse / lõhutakse.
  3. Parooliräsi tegemiseks peaksin selle sadu või tuhandeid kordi käima üle md5 või muu.

Artiklis öeldakse, et soolatud räsi on liiga lihtne lõhkuda ja soovite valida parooli räsi, kuna paroolide kontrollimiseks on see arvutuslikult pikem, nii et te ei saa nii palju sekundis teha.

Ma arvan, et 3 tegemine on turvalisuse jaoks halb ja 1 on tegelikult parim variant. Mida teie arvate?

Neli vastused:
Hendrik Brummermann
2012-06-17 22:42:44 UTC
view on stackexchange narkive permalink

Soolaga krüptograafiline räsi (nagu md5) on halb.

Sellest ei piisa enam. Traditsioonilised krüptograafilised räsifunktsioonid on mõeldud dokumentide jaoks ja seetõttu on need kiiruse jaoks optimeeritud.

Kuid kiirus on just see, mida me paroolirässide jaoks ei soovi. Kaasaegsed graafikakaardid suudavad sekundis teha 2 000 000 000 SHA1 või MD5 räsimist. Nii et 6-tähemärgilise parooli jõhker sundimine võtab vähem kui 10 minutit.

Unixi varifailide lõhkumine / lõhkumine pole haruldane.

See kehtib ka neis kasutatud vanad räsid.

Parooliräsi tegemiseks peaksin selle käivitama üle md5 või mis tahes muu sadu või tuhandeid kordi.

Kuigi see on Olen parem, kui kasutada vaid kiiret räsifunktsiooni, kuid see ei ole piisav.

Peaksite kasutama ühte räsikrüptimise algoritme (v.a md5crypt): sha256crypt, sha512crypt, bcrypt või scrypt. Need on algoritmid, mis on kavandatud suhteliselt aeglaseks ja pole graafikakaartidel hõlpsasti rakendatavad, et jõudlust suurendada.

Need algoritmid teevad midagi enamat kui lihtsalt ühe vooru väljundi kasutamine järgmise vooru sisendina. Reeglid, mida sisendina kasutada, varieeruvad sõltuvalt iteratsiooniloendurist (vt lingitud spetsifikatsioone). Kaasaegne unixi operatsioonisüsteem kasutab faili sha512crypt.

scrypt läheb teistest algoritmidest ühe sammu kaugemale, sest lisaks skaleeritavale protsessori kasutamisele kasutab scrypt palju mälu. Idee on muuta paroolikrakkerite riistvaralised rakendused palju kallimaks. Sellisel riistvaral on tavaliselt juurdepääs kuni 1KB kiirele mälule, kuid scrypti vaikeparameetrid nõuavad 16MB.

Selle artikli ilus tsitaat on: "See on tõeliselt levinud eksiarvamus - ka turvainimeste seas -, et siin on probleemiks SHA-1 kasutamine. See poleks üldse oluline, kui nad oleksid kasutanud SHA-512, neil poleks parem üleüldse." mis muidugi ei saanud tõest kaugemal olla. Autor põhjendab, et kuna saate selle võrguühenduseta ühenduse pakkumisel purustada, on see kõik sama, mis on muidugi vale.
Sam Whited
2012-06-18 04:20:05 UTC
view on stackexchange narkive permalink

Krüptograafiline räsi (nt md5) soolaga on halb.

Ma ei lugenud artiklit, kuid seda võis lugeda kahel viisil:

  1. MD5, isegi kui soolatud on halb.
  2. Soolatud räsid on halvad.

Vastuseks esimesele on jah, see on tõsi . MD5 on osutunud ebakindlaks ja on liiga kiire, et olla igal juhul turvaline räsimisfunktsioon. Ärge kasutage MD5.

Teise osas on see täiesti vale. Soola oma räsi alati. See aitab ära hoida vikerkaart rünnakute eest.

Unixi varifailide lõhkumine / lõhkumine pole haruldane.

See tõsi, enamik inimesi valib ebaturvalised paroolid, mida on üsna lihtne murda. Loo lõpp. Klassikaline turvatööriist selleks on Ripper Johannes. Isegi tänapäevaseid räsi kasutavad varifailid kasutavad sageli liiga kiireid algoritme, et tõesti palju kaitset pakkuda (vt allpool).

Parooliräsi tegemiseks peaksin selle käivitama üle md5 või muu, mis on sadu või tuhandeid kordi.

Varem oli see tõsi. Selle põhjuseks on muuta see paroolikatsete tegemisel palju aeglasemaks (kuna peate palju räsimisalgoritmi käivitama). Isegi kaasaegse räsi nagu SHA2 puhul on see sageli nii kiire, et halvasti valitud parooli jõhker sundimine võib võtta mitu päeva või isegi tundi.

Kaasaegsed kokkuvõtte algoritmid võtavad seda arvesse ja on mõeldud olema arvutuslikult või mälumahukas. Levinumad näited hõlmavad bcrypt, mis sisaldab soola ja on arvutuslikult kulukas. Uuem algoritm, scrypt, on viimasel ajal natuke tähelepanu saanud, kuna see on ka mälumahukas (muutes GPU-de kräkkimise palju keerulisemaks).

Oleksi
2012-06-17 06:45:48 UTC
view on stackexchange narkive permalink

Miks teie arvates on 3 turvalisusele halb? Tegelikult peaksite paroolide räsimiseks kasutama midagi sellist nagu bcrypt, et kogu seda segadust vältida.

Bcrypt ühendab need omadused. See räsib parooli soola kasutades mitu korda, et luua aeglane ja turvaline räsimisfunktsioon, mis tekitab krüptograafiliselt turvalisi räsisid.

Kas sool või räsi muster ei asenda algset parooli, nii et 100 000 korda tehes muudaks mis tahes sisend kehtiva parooli? (selline keeruline / 2. Lõpuks saab sellest üks või null, välja arvatud natuke mustrit)
@acidzombie24 Ei. Nii ei toimi räsimisfunktsioon.
user10211
2012-06-17 08:06:05 UTC
view on stackexchange narkive permalink

1 on kohustuslik. Soolad on väga olulised selle tagamiseks, et paroole ei saaks hõlpsasti murda, kui võrrelda neid vikerkaarega.

Miks peate kolme halvaks? See on tehnika, mida nimetatakse klahvide venitamiseks. Ja see suurendab märkimisväärselt paroolide purustamiseks vajalikku aega ja arvutusvõimet.

Mis puutub 2-sse, siis ütleksin, et pole haruldane varifaili salvestatud tavaliste / halbade paroolide krakkimine. Head paroolid (väga juhuslikud, tähtnumbrilised jne) peaksid siiski olema suhteliselt ohutud.

Kas sool või räsi muster ei asenda algset parooli, nii et 100 000 korda tehes muutuks mis tahes sisend kehtivaks parooliks? (selline keeruline / 2. Lõpuks saab sellest üks või null, välja arvatud natuke mustrit)
Ei, loe lähemalt, kuidas räsimine töötab.
@acidzombie24, kehtib mõne räsifunktsiooni kohta (nt arvus olevate numbrite summa). Krüptograafilised räsifunktsioonid peaksid aga olema vastupidavad.


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...