Kysymys:
"Oikea" suola ja "väärennetty" suola
Jeff Ferland
2011-08-09 18:32:43 UTC
view on stackexchange narkive permalink

Q&A-jakson aikana DEFCONissa tänä vuonna yksi yleisön jäsen mainitsi, että käytämme "väärennettyä suolaa" liitettäessä satunnaisarvo ja salasana ennen hajauttamista. Hän määritteli "todellisen suolan" sellaiseksi kuin se näkyy alkuperäisessä Unix-salauksen toteutuksessa, joka muutti algoritmin toimintaa, mikä vaati eri koodin käyttöä jokaisen salasanan murtamiseen ja erittäin huolestuttaviin GPU-hyökkäyksiin.

Onko mitään ansioita "todelliseen" ja "väärennettyyn" suolakeskusteluun?

Olen myöhässä juhliin, mutta [Donald Knuthin anekdootti satunnaistetuista algoritmeista] (http://www.informit.com/articles/article.aspx?p=2221790) on otettava huomioon.Salattujen satunnaislukujen luominen on jo vaikeaa;sen tekeminen * satunnaistetulla algoritmilla * on käytännöllisesti katsoen epäonnistunut ja epäonnistuu näyttävästi.
Kuusi vastused:
#1
+46
Thomas Pornin
2011-08-09 19:27:53 UTC
view on stackexchange narkive permalink

Ero on mielivaltainen. Suolatietoinen algoritmi toimii ottamalla syötetiedot ja salaamalla ne eri tavoin, eikä suolan lisäämiseen ole menetelmää, joka olisi enemmän tai vähemmän "väärennetty" kuin mikään muu.

Yritetään suunnitella salasana. käsittelyalgoritmi, joka on tehokas yleiskäyttöisessä prosessorissa, mutta ei skaalaa hyvin GPU: lla (tai mukautetulla FPGA: lla tai ASIC: lla) on todellinen tutkimusaihe. Tästä scrypt on kyse, ja epäilemättä bcrypt tekee jo hyvää työtä siinä. Ajatuksena on käyttää pääsyjä taulukoissa, joita muokataan jatkuvasti; RAM-pöydän käyttöoikeus on sellainen, että yleiskäyttöinen keskusyksikkö on hyvä, mutta mikä vaikeuttaa GPU: n asioita (he voivat tehdä sen, mutta ei niin täydellä rinnakkaisuudella kuin mitä yleensä saadaan GPU: lla).

+1 OP: n "väärennetty suola" on ylivoimaisesti yleisin termin "suola" käyttö - ja koska yleisön jäsenen "todellinen suola" ei tarjoa mitään etuja "väärään suolaan" verrattuna, ero on turha. Yleisön jäsen yritti olla pedanttinen näyttämään fiksulta ja epäonnistui.
#2
+21
gowenfawr
2011-08-09 19:08:30 UTC
view on stackexchange narkive permalink

Kyllä, on tehtävä pätevä ero; tarvitset salauslääkärin kertomaan sinulle, kuinka merkityksellinen ero on.

Kuvaamaasi "todellista suolaa" käytetään "häiritsemään salauksen algoritmia". Ymmärrän sen epämääräisesti, mutta ei tarpeeksi hyvin kuvaamaan oikein. Riittää, kun todetaan, että todellisella suolalla alkuperäinen salasanan teksti salataan, mutta sillä on erilaiset lähdöt sen mukaan, miten algoritmi sisältää suolan syötteen (algoritmissa on (vähintään kaksi) syötettä, suola ja (erikseen) alkuperäinen salasanateksti).

"Fake salt" tarkoittaa alkuperäisen salasanatekstin muokkaamista suolalla ennen salaamista salausalgoritmilla. Esimerkiksi, jos salasanani on "nezperce" ja suolani on "qp", niin algoritmille annetaan koodattu muokattu salasanateksti "qpnezperce". Jos Alice yrittää myös käyttää salasanaa "nezperce", mutta sillä on suola "w4", algoritmi koodaa hänelle muokatun salasanatekstin "w4nezperce". Seurauksena on, että hänen salattu hash eroaa omastani, vaikka me molemmat käytämme samaa salasanaa.

Molemmat menetelmät tarjoavat suolan ensisijaisen edun; varmistaa, että samaa salasanaa ei aina salata samalla tavalla. Suolojen käyttö lisää ennalta lasketun hash-hyökkäyksen asentamisen vaikeuksia (aiemmin sanoin sanakirjan tai raakavoiman hyökkäyksen, katso kommentit).

Uskon, että "todellisen suolan" käytöllä on muita etuja, kuten lisääntyneenä laskennallisena yleiskustannuksena (mikä hidastaa hyökkäyksiä). Mutta jälleen kerran tarvitset jonkun, jolla on enemmän salaustaitoja kuin minä, jotta tiedän, onko se totta vai ei.

Mielestäni "väärennetyn suolan" etuna on, että se on helpompi toteuttaa ja vaatii vähemmän salausta taju. Tiedän, että paikka, jonka olen nähnyt yleisimmin väärennettyjä suoloja, ovat verkkosovellukset, jotka hallinnoivat omaa todennustietokantaansa.

Fantastinen ero, en ajatellut sitä tällä tavalla. Kiitos viestistä gowenfawr
Haluan täsmentää, että suola auttaa ennalta laskettuja hyökkäyksiä (tai hashien etsimistä) vastaan. Se ei ehkä ole niin hyödyllistä raakaa voimaa ja sanakirjahyökkäyksiä vastaan ​​live-järjestelmässä / kirjautumislomakkeessa.
@Bushibytes, hyvä asia - Minulla on tapana ajatella ennalta laskettuja hyökkäyksiä raakojen voimien hyökkäyksinä, mutta se ei ole totta ... ennalta lasketun haun luominen on raakaa voimaa, mutta raakan voiman hyökkäys edellyttää suoraa vuorovaikutusta. Yritän muokata sen selventämiseksi.
Näyttää siltä, ​​että ero ei ole algoritmiin syötetyssä suolatiedossa, vaan itse algoritmissa. Perinteinen algoritmi vie avaimen ja viestin. Jos haluat pakottaa toisen syötteen (suola), voit mukauttaa yhteen joitain algoritmeja. ts. E (avain, viesti) sijasta teet E (E (avain, suola), viesti) Kolmelle tulolle suunniteltu algoritmi on menestyksekkäämpi kuin kahdelle tulolle suunniteltu algoritmijärjestelmä.
gowenfawrin vastaus on täysin väärä. Yksi tapa nähdä tämä: huomaa vain, että riippumatta siitä, käyttääkö järjestelmä sitä, mitä gowenfawr kutsuisi "todelliseksi suolaksi" vai "vääräksi suolaksi", voit rakentaa yhden kiinteän piirin C kiinteällä porttisarjalla kiinteässä piirissä topologia, joka laskee hajautetun salasanan hash = C (salasana, suola). On selvää, että tässä piirissä se on sama laskenta ja samat portit suolasta riippumatta. Lyhyesti sanottuna tämä liiketoiminta "algoritmin häiritsemisestä" on puhdasta balderdashia.
#3
+7
nealmcb
2011-08-15 22:06:20 UTC
view on stackexchange narkive permalink

Kuten Thomas huomautti, yleinen käsitys pelkästään suolan käyttämisestä muokkauksena hajautusalgoritmiin ei todellakaan saa sinulle mitään lisäsuojaa. Se voi vaatia hyökkääjää mukauttamaan olemassa olevia ohjelmisto- ja laitteistohyökkäyksiä, mutta se voi myös aiheuttaa sinulle ongelmia, jos et todellakaan tiedä, mitä olet tekemässä.

Mutta heiltä puuttui toinen vanha innovaatio alkuperäinen paperi suolaamisesta - mitä yleensä kutsutaan "pippuriksi": mukautettu avain, joka on osa toteutusta ja jota ei ole tallennettu salasanojen mukana. Viittaan tapaan, jolla Morris ja Thompson esittivät kyseisen konseptin myös seminaarissaan Unix-artikkelissaan keskustelussa Password Hashing lisää suolaa + pippuria vai riittääkö suolaa?

Pippurilla on etu, että voit käyttää sitä yhdessä suolan kanssa, niin että vaikka joku varastaisi salasanatietokannan (jossa on suoloja), heidän olisi myös varastettava pippuri (ehkä sisällytetty sovellukseen tai hajautuskirjastokoodiin tai tallennettu täysin erillisessä järjestelmässä) salasanojen murtamiseksi. Monissa tapauksissa se ei ole paljon vaikeampi, mutta joissakin tapauksissa se voi olla huomattavasti vaikeampaa.

#4
+5
M15K
2011-08-09 19:04:25 UTC
view on stackexchange narkive permalink

Ei tunne alkuperäisen Unix-salauksen käyttöönoton yksityiskohtia. Mutta sillä ei näytä olevan järkevää minulle. Varsinkin kun otetaan huomioon salasanojen suolaamisen tarkoitus. Luulen, että jos suolan käyttäminen muuttaa algoritmiasi vahvemmaksi, käytät ensinnäkin väärää algoritmia.

#5
+3
GuloGulo
2011-08-15 19:57:44 UTC
view on stackexchange narkive permalink

Olin myös keskustelussa ja olin se, joka istui molempien kryptografien kanssa keskustelun aikana. Todellinen suola väärennettyyn suolaan kiehtoi minua. Nyt anna anteeksi, koska minulla ei ole muistiinpanojani edessäni, mutta todellisen suolan turvallisuudessa on valtava ero verrattuna väärennettyyn suolaan. avain, kun se menee lohkon salakoodiin, joten pelkkä teksti (salasana) ei ole ainutkertainen, ja avain, jolla selvitetään, kuinka iteraatiot tapahtuvat, on myös ainutlaatuinen. Algoritmia säätämällä todellisen suolan rikkoutuminen on eksponentiaalisesti vaikeampi kuin väärennetyn suolan.

Antaa siis käyttää esimerkkiä tämän kuvaamiseen. Tässä esimerkissä käytän MD5-hashia (en muista, voitko käyttää todellista suolaa MD5: ssä, vaikka älä liekki minua tästä) sekä todellisen suolan että väärennetyn suolan kanssa. käyttämällä CUDA-Multiforceria GPU-salasanan halkaisijana. Haluaisin yrittää tavallista MD5: tä vastaan ​​yrittää murtaa salasanan, mutta koska olen suolannut salasanan, se voisi toimia ikuisesti suolan (tosi tai väärennetty) perusteella. Nyt osa minulle annetusta kuvauksesta oli kyky murtaa väärennetty suola ja kuinka kesti vain vähän kauemmin laskea / murtaa hajottamalla hash palasiksi. En seurannut heidän sanojaan, jotta voisin olla kaukana siitä. Nyt voidaan olettaa, että pystyimme hankkimaan salasanasuolan (väärä). Käyttämällä väärennettyä suolaa, syötämme sen vain salasanan halkaisijamme ja jatkamme raakaa voimaa, kunnes voimme sovittaa hajautukset. Ei kovin vaikea tehdä ja toimii melko nopeasti.

Jos käytämme todellista suolaa, hassien murtaminen olisi eksponentiaalisesti vaikeampaa ja pidempään. Käyttämällä todellista suolaa minun olisi todella kirjoitettava osa CUDA-Multiforcerista käyttämään todellista suolaa käytetyn algoritmin kanssa. Muista, että se muuttaa salauksen avainta, mikä tarkoittaa, että se ei ole vain yksinkertainen tekstimuutos, se on algoritmin muutos, joten minun on muutettava koodia tehdäksesi tämän. Okei, joten nyt olemme muuttaneet salasanan crackerin toimintaa, törmäämme nyt nopeusongelmaan. Avaimen vaihdon myötä jokainen salasana testataan nyt melko vähän kauemmin, koska se muuttaa nyt kullekin raakalle pakotetulle salasanalle käyttämääsi iteraatiota. He olivat molemmat antaneet minulle esimerkkejä nopeuden eroista, ja mielestäni väärennetyn suolan kanssa se oli noin miljoona sekunnissa, ja todellinen suola oli noin

#6
+2
Soren
2011-08-09 22:34:49 UTC
view on stackexchange narkive permalink

Ero väärennetyn suolan ja todellisen suolan välillä tekee eron vain, jos hajautusalgoritmit ovat piilossa hyökkääjälle. "todellinen suola", joka määrittää hajautusalgon muunnoksen avoimessa standardissa hajautusalgossa, voidaan helposti toteuttaa GPU: lla / hajautetulla hyökkäyksellä, koska kaikki syötteet ovat hyökkääjän tiedossa ja siten osa-algo voidaan helposti määrittää ennen aika.

Varhainen Unixin hajautusalgo salasanoille (kuten muistan sen Bell System V7: stä) EI antanut salasanan hajautuksen algoa - se oli ainoa osa järjestelmää, jota varten voit vain hanki .o-tiedosto, josta yliopistot saivat lähdekoodin kaikesta muusta.

Joten ehdotat turvallisuutta epäselvyydellä?
@Earlz Ei - Ehdotan, että todellisella suolalla vs. väärennetyllä suolalla on merkitystä vain silloin, kun epävarmuus on osa turvallisuutta.


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