Kysymys:
Mitä siirtää? Salasana vai sen hash?
Konrad Garus
2011-06-30 17:47:31 UTC
view on stackexchange narkive permalink

Oletetaan, että tallennan tietokantaani suolalla hajautettuja salasanoja melko kalliilla hashilla (scrypt, 1000 kierrosta SHA2: ta, mikä tahansa).

Mitä minun pitäisi kirjautumisen yhteydessä siirtää verkon kautta ja miksi? Salasana tai sen hash?

Voiko tällaisen kirjautumisen suojata salaamattomalla kanavalla, kuten HTTP?

Onko tämä retorinen kysymys? (Tarkoitettu herättämään uteliaisuutta ja keskustelua?) Vai onko sinulla todellinen toteutusvaatimus todentamaan HTTP: n kautta? Se on mielenkiintoinen kysymys, mutta yksinkertainen vastaus on "käytä SSL: ää", ja on hyvin vähän syitä, miksi hyvä järjestelmä poikkeaisi siitä.
Neljä vastused:
#1
+62
AviD
2011-06-30 17:54:52 UTC
view on stackexchange narkive permalink

Jos siirrät hajautusasiakkaan asiakkaalta, se ei tarjoa tietoturvaetua ja tekee hajautuksesta turhaa:
Jos käyttäjä voi kirjautua sisään lähettämällä hajautuksen palvelimelle, hajautus on käytännössä salasana.

Hajauttaminen asiakkaalle tuottaa käyttäjälle jonkin verran hyötyä, koska hyökkääjä ei vaaranna salasanaansa, mikä vaarantuessaan avaisi käyttäjälle mahdollisuuden saada muita heidän hallussaan pitämiä tilejä, jos he ovat käyttäneet samaa salasanaa (jota et voi estää ). Tämä ei tarkoita sitä, että asiakas on paras paikka hajauttaa, mutta jos mitään muuta hajautusta ei tehdä, asiakkaalla ** on ** tietynlainen turvallisuusetu.
Jos joku pystyi salakuuntelemaan hashin, hän saisi alkuperäisen salasanan muuten.Kuinka se voisi olla parempi vaihtoehto ?!
Uhh wut @NikitaVolkov?Juuri sen sanoin, se EI ole parempi vaihtoehto.
Kommenttini koskee "tämä ei tuota mitään turvallisuusetua ja tekee hashista turhaa".
Aivan, tarkalleen ....?Etkö ole varma, mitä tarkoitat, sanoin, että hash-lähetyksestä ei ole mitään hyötyä tietoturvasta, ja tietoturvasta poV ei olisi parempi vaihtoehto?
Luulen, että salasanan suojaaminen hashilla tarjoaa lisäsuojausta, eikä ole sama asia, joka lähettää hash salasanan sijaan, koska joskus käyttäjä käyttää samaa salasanaa (tai pieniä muunnelmia, jotka lisäävät yhden merkin) muilla verkkosivustoilla / palveluissa.Yleensä tietoturvasta kertovat rivit eivät ole hyviä, että salasana voidaan lukea selvästi.
Etkö voisi valmistaa jotain, johon liittyy ei-käyttöoikeus ja jaettu salaisuus, jotta vain palvelin ja asiakas voivat lähettää kyseisen hashin?Odota, että kuvasin juuri jotain, kuten TLS, en minä.
@JefersonTenorio: tä ei tietenkään pidä lukea salasanaa selkeästi, se on TLS.Tarkoitus on, jos et käytä TLS: ää, tosiasiallisesti lähettämäsi hash * on * salasana - eikä sillä ole väliä, koska lähetät edelleen * että * selkeässä tekstissä.(Ja jos käytät TLS: ää, niin sillä ei ole merkitystä).
@Adonalsium joo mitä sanoit ;-)
#2
+24
Thomas Pornin
2012-10-28 20:54:54 UTC
view on stackexchange narkive permalink

Jos todennusprotokolla koskee salasanan tai salasanan tiivisteen lähettämistä palvelimelle tavallisella HTTP: llä, se on luonnostaan ​​hyvin heikko kahdesta syystä:

  • Joku vakooja linjaa voisi tallentaa, mitä asiakas lähettää. Jos vain näiden tavujen lähettäminen antaa pääsyn, hyökkääjä voi yksinkertaisesti lähettää ne uudelleen. Se on uusintahyökkäys. Tätä asiaa @AviD viittaa vastauksessaan. Mikään hajautus ei korjaa sitä. Jotkut protokollat ​​yrittävät korjata tämän ongelman sisällyttämällä palvelimelta "haasteen" (satunnaisarvo, joka on luotu uudestaan ​​kullekin yhteydelle), joka hajautetaan yhdessä asiakkaan salasanan kanssa. siitä on kyse HTTP Digest -todennuksessa.

  • Vaikka todennus toimisi, tämä on silti yksinkertainen HTTP, joten mitä tietoja lähetetään jälkeenpäin ovat alttiita hyökkääjien salakuuntelulle ja muutoksille. Jos siirtoväline on suojaamaton, todennus estää vain kaikkein kehittyneimmät hyökkääjät. Täällä HTTP-yhteenveto epäonnistuu.

Siksi todella tarvitset SSL: n (alias HTTPS), ei vain salasanan tai sen tiivisteen välittämiseen, mutta myös loppuosa asiakkaan ja palvelimen välisestä keskustelusta.


Oletan tämän jälkeen, että protokolla suoritetaan SSL-tunnelissa. Sinulla on oikeus haluta käyttää hidasta hash ia, kuten bcrypt tai PBKDF2; Huomaa, että suola tarvitaan myös kustannusten jakamisen estämiseksi (esim. valmiiksi lasketut taulukot). Hidas, suolattu hajautus käytetään selviytymään salasanojen sisäisestä heikkoudesta. Nyt saatat haluta purkaa osan hajautuksesta asiakkaalle. Tämä saattaa toimia, mutta se herättää joitain käytännön asioita:

  • Koska salasanan käsittelyssä on oltava suola, uusi kullekin salasana-ilmentymälle, suola on välitettävä asiakkaalle, jotta asiakas voi sisällyttää sen suorittamaansa hajautukseen. Tämä lisää protokollan monimutkaisuutta: asiakkaan on ensin lähetettävä käyttäjänimi palvelimelle, sitten palvelimen on lähetettävä suola takaisin ja (vasta sitten) asiakas voi alkaa hajauttaa salasanaa. Tämä on yksi verkon meno-paluu enemmän kuin tavallisella "lähetä käyttäjänimi ja salasana yhdeksi POST-pyynnöksi".

  • Hidas hajautus tarkoittaa sitä, että suostut kuluttamaan paljon suorittimia kullekin salasanalle , joten hyökkääjän myös on käytettävä paljon keskusyksikköä jokaiseen salasanaan. Mutta jos käytetty suoritin on asiakkaalla, emme voi nostaa sitä niin paljon kuin haluaisimme, koska: 1) on asiakkaita, joilla on hyvin vähän suorittimia (esimerkiksi joitain halpoja älypuhelimia tai tabletteja), ja 2) verkkokonteksti viittaa Javascriptin käyttäminen ja Javascriptin suorituskyky on todella huono hajautuksen suhteen (sano vähintään 20 kertaa hitaammin kuin C-koodi).

Siksi tavallinen viisaus on, että osa salasanan hajauttamisesta asiakkaalle ei ole vaivan arvoista.

#3
+4
Dog eat cat world
2011-06-30 17:58:30 UTC
view on stackexchange narkive permalink

Molemmat vaihtoehdot ovat epävarmat.

Salasanan siirtäminen tekee protokollastasi pelkkää tekstiä. Hajautuskoodin siirtäminen tekee alttiiksi uusintahyökkäyksille.

APOP on kirjautumistoteutus POP-protokollalle. Tämä sallii protokollan pitää salasanan yksityisenä verkon kuuntelijoilta. Haittana on, että sekä asiakkaan että palvelimen on tiedettävä salasana pelkkänä tekstinä, koska tämä on jaettu salaisuus. Ennen asiakasta ja palvelinta on protokollan salasanan kanssa <-salasana> Protokollayhteys on periaatteessa näin:

  1. Asiakas muodostaa yhteyden palvelimeen ja lähettää satunnaisen tunnuksen (T1)
  2. Palvelin lähettää satunnaisen tunnuksen (T2)
  3. Asiakas lähettää M = sha (T1 + T2 + <-salasana: asiakkaan kopio>) palvelimelle
  4. Palvelin tarkistaa, onko sha (T1 + T2 + <-salasana: palvelimen kopio>) M (juuri saatu hash).

Tässä palvelin tuntee sekä taikuuden että salasanan ja pystyy selvittämään, tietääkö käyttäjä oikean salasanan altistamatta sitä kenellekään kuuntelijalle.

paras käytäntö olisi hashien turvallinen tallentaminen tietokantaan ja luottaminen salattuihin kanaviin

Se on edelleen haavoittuvainen MitM: lle, jos haistelija sieppaa T1: n, välittää sen palvelimelle, sama kuin T2: lla, se voi luoda oman sha: n (T1 + T2 + ...).
Tosin, MitM-haavoittuvuus on mahdollisuus pakottaa hash uudelleen rekonstruoimaan alkuperäinen salasana, kun T1 ja T2 tiedetään. Toistohyökkäykset eivät kuitenkaan ole mahdollisia, jos T1: tä ja T2: ta ei käytetä uudelleen (lisäsi aikaa jne.).
http://fi.wikipedia.org/wiki/Needham%E2%80%93Schroeder_protocol on hyvä esimerkki samanlaisesta protokollasta, hyökkäyksestä ja korjauksesta. Hyvä lukeminen.
@Marcin En ole vieläkään vakuuttunut siitä, että tämä on altis MitM-hyökkäykselle. Jotkut pisteet jätetään pois alkuperäisestä vastauksesta, mutta ne voidaan helposti korjata valitsemalla kertakäyttöisiä satunnaisia ​​merkkejä. Ensimmäisessä kommentissasi kuvannut MitM-hyökkäys ei paljasta jaettua salaisuutta, koska sitä ei koskaan lähetetä. Istunto voidaan kaapata sisäänkirjautumisen jälkeen, mutta se voidaan korjata myös allekirjoittamalla tai salaamalla loput istunnoista jaetulla salaisuudella (salasanalla).
Käytätkö shaa (T1 + T2 + mitä tahansa) salausavaimena data xferille tai vain todennukselle?
Sitä käytetään todentamiseen sen varmistamiseksi, että molemmilla osapuolilla on sama riippumatta / "jaetusta salaisuudesta". Protokollaa voidaan tietysti laajentaa käyttämään tätä jaettua salaisuutta salatun kanavan luomiseen. Mutta tämä on toinen keskustelu, johon liittyy muita heikkouksia tämän soveltamisalan ulkopuolella.
Tämä on mielenkiintoinen algoritmi, mutta se on asian vieressä: et välttämättä vuoda salasanaa, mutta mikä järkeä sinulla on salasanalla, jos et aio turvata loppuistuntoa? Yli http: n keskellä oleva mies ei ehkä saa käyttäjän salasanaa, mutta hän näkee kaiken sisällön, joka on siirretty istunnon aikana, ja jos istunnon tunnusta käytetään, MITM voi kaapata käyttäjän istunnon. Ellei tämä ole retorinen kysymys, oikean vastauksen on oltava: "käytä SSL: ää".
Onko APOPia käytettäessä mitään syytä olla käyttämättä salasanojen vaihtoa tavanmukaisella tavalla, jotta palvelimelta ei vaadita salasanaa, jota ei tarvitse sekoittaa? Joku, joka saa kopion palvelimen hajautetusta salasanasta, voisi esiintyä käyttäjänä kyseisellä sivustolla, mutta ei voisi käyttää salasanaa missään muussa sivustossa.
#4
-1
ewanm89
2011-07-02 01:12:03 UTC
view on stackexchange narkive permalink

Kumpikaan, Ihannetapauksessa käytetään haastevastausmekanismia ja siirretään sitten hash ja tehdään kaikki tämä salauksella suojatulla kanavalla kuten SSL. Mutta useimmat käyttäjät eivät pidä siitä, että kirjautumiseen kuluu 5 minuuttia. Lisäksi käyttäjän tulisi tarkistaa tämä kaikki ennen käyttöä.

Se riippuu viime kädessä siitä, kuinka paljon tarvitset tietoturvan ja mitä hyökkäysvektoreita yritetään suojata, mutta SSL: n käyttö on aina hyvä idea.

SSL: n käyttö on kaikki mitä tarvitaan. SSL: n käyttäminen ei tee "kirjautumiseksi 5 minuuttia". Pessimismin taso tässä ei ole perusteltua.
Olen tietysti päättänyt siitä. Se, mitä voimme tehdä ja mikä on järkevää tietyssä tilanteessa, on kaksi erilaista asiaa


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