Kysymys:
Mitä hyötyä asiakkaasta on?
user700503
2011-04-10 07:56:56 UTC
view on stackexchange narkive permalink

Luettuani Ross Andersonin kirjan osan I, Turvallisuustekniikka , ja selvittämättä joitain aiheita Wikipediassa, törmäsin ajatukseen Client Noncesta (cnonce). Ross ei koskaan mainitse sitä kirjassaan, ja yritän ymmärtää tarkoitusta, jolla sitä käytetään käyttäjien todennuksessa.

Normaalia nonce-arvoa käytetään välttämään uusintahyökkäyksiä, joihin liittyy vanhentuneen vastauksen käyttöoikeuksien saaminen. Palvelin toimittaa asiakkaalle nonce-numeron (käytetty numero kerran), jota asiakas on pakko käyttää vastauksensa hajauttamiseen, palvelin hajauttaa odotuksensa vastauksen antamallaan ei-vastauksella ja jos asiakkaan hajautusarvo täsmää palvelin voi sitten tarkistaa, että pyyntö on pätevä ja uusi. Tämä on kaikki, mitä se tarkistaa; kelvollinen ja tuore .

Selitykset, jotka olen löytänyt asiakaskoneelle, eivät kuitenkaan ole yhtä suoraviivaisia ​​ja kyseenalaisia. Digitaalisen pääsyn todennuksen Wikipedia-sivu ja useat vastaukset täällä Stackoverflow'ssa näyttävät viittaavan siihen, että asiakaskoneita käytetään valittujen selkokielisten hyökkäysten välttämiseen. Minulla on useita ongelmia tämän ajatuksen kanssa:

  • Jos joku osaa nuuskia ja lisätä paketteja, suurin haavoittuvuus on ihminen keskellä -hyökkäys, jota ei kukaan ei ei voi voittaa, siten tekee molemmista merkityksettömiä.
  • Oletetaan hetkeksi, että hyökkääjä ei halua osallistua välimies-hyökkäykseen ja haluaa palauttaa todennustiedot, miten cnonce tarjoaa lisäsuojaa ? Jos hyökkääjä sieppaa viestinnän ja vastaa pyyntöön omalla nonce-toiminnollaan, asiakkaan vastaus on salauksen ulkopuolisen cnoncen lisäksi hass, nonce, data ja cnonce. Nyt hyökkääjällä on pääsy nonceen, cnonceen ja hashiin. Hyökkääjä voi nyt hajauttaa sateenkaaripöydänsä noncen ja cnoncen kanssa ja löytää ottelun. Siksi cnonce tarjoaa nollan lisäsuojauksen.

Mikä siis on cnoncen tarkoitus?

Oletan, että yhtälössä on jokin osa, jota en ymmärrä, mutta en ole vielä löytänyt selitystä osan osalle.

MUOKKAA Joitakin vastauksia on ehdotti, että asiakas voi tarjota nonce-palvelun ja se palvelee samaa tarkoitusta. Tämä kuitenkin rikkoo haaste-vastausmallin, mitkä ovat tämän seuraukset?

Neljä vastused:
#1
+141
Thomas Pornin
2011-04-11 18:03:24 UTC
view on stackexchange narkive permalink

nonce on yksilöllinen arvo, jonka entiteetti on valinnut protokollassa, ja sitä käytetään kyseisen yksikön suojaamiseen hyökkäyksiltä, ​​jotka kuuluvat hyvin suuren "replay" -sarjan alle.

Harkitse esimerkiksi salasanapohjaista todennusprotokollaa, joka toimii näin:

  • palvelin lähettää "haasteen" (oletettavasti satunnainen arvo c ) asiakas
  • asiakkaan on vastattava lähettämällä h (c || p) , jossa h on suojattu hash-toiminto (esim. SHA-256), p on käyttäjän salasana, ja ' || ' tarkoittaa ketjutusta.
  • palvelin etsii salasanan omasta tietokannastaan, laskee odotetun asiakkaan vastauksen ja näkee jos se vastaa asiakkaan lähettämää sisältöä

Salasanat ovat salaisia ​​arvoja, jotka sopivat ihmisen aivoihin; sinänsä ne eivät voi olla kovin monimutkaisia, ja on mahdollista rakentaa iso sanakirja, joka sisältää käyttäjän salasanan suurella todennäköisyydellä. "Suurella" tarkoitan, että "voidaan luetella keskisuurella klusterilla muutamassa viikossa". Nykyisessä keskustelussa hyväksytään, että hyökkääjä voi rikkoa yhden salasanan viettämällä muutaman viikon laskennan. tämä on turvallisuustaso, jonka haluamme saavuttaa.

Kuvittele passiivinen hyökkääjä: hyökkääjä salakuuntelee, mutta ei muuta viestejä. Hän näkee c ja h (c || p) , joten hän voi käyttää klusteriaan luetteloiden mahdollisia salasanoja, kunnes vastaavuus löytyy. Tämä on hänelle kallista. Jos hyökkääjä haluaa hyökätä kahteen salasanaan, hänen on tehtävä työ kahdesti . Hyökkääjä haluaa jakaa kustannukset kahden hyökkäyselimen välillä käyttämällä esilaskettuja taulukoita ("sateenkaaritaulukot" ovat vain eräänlainen ennalta laskettu taulukko, jossa on optimoitu tallennustila; mutta sateenkaaripöydän rakentaminen edellyttää kuitenkin koko sanakirjan luetteloimista ja kunkin salasanan hajauttamista). Satunnainen haaste kuitenkin hyökkää hyökkääjän: koska jokaiseen esiintymään liittyy uusi haaste, hajautusfunktion syöttö on erilainen jokaisessa istunnossa, vaikka samaa salasanaa käytetään. Hyökkääjä ei siis voi rakentaa hyödyllisiä ennalta laskettuja taulukoita, etenkään sateenkaaripöytiä

Oletetaan, että hyökkääjä aktivoituu. Sen sijaan, että vain tarkkailisi viestejä, hän muuttaa aktiivisesti viestejä, pudottaa joitain, kopioida toisia tai lisätä omia viestejä. Hyökkääjä voi nyt siepata yhteysyrityksen asiakkaalta. Hyökkääjä valitsee ja lähettää oman haasteensa ( c ') ja odottaa asiakkaan vastausta ( h (c' || p) ). Huomaa, että todelliseen palvelimeen ei oteta yhteyttä; hyökkääjä vain katkaisee yhteyden äkillisesti heti asiakkaan vastauksen jälkeen hyvänlaatuisen verkkovirheen simuloimiseksi. Tässä hyökkäysmallissa hyökkääjä on tehnyt suuren parannuksen: hänellä on edelleen haaste c ' ja vastaava vastaus, mutta haaste on arvo, jonka hyökkääjä on valinnut sopivaksi. Hyökkääjä tekee aina palvelemaan saman haasteen c '. Saman haasteen käyttäminen joka kerta antaa hyökkääjälle mahdollisuuden suorittaa ennakkolaskelmia: hän voi rakentaa ennalta laskettuja taulukoita (eli sateenkaaripöytiä), jotka käyttävät kyseistä erityistä "haastetta". Hyökkääjä voi nyt hyökätä useisiin erillisiin salasanoihin ilman, että kullekin aiheutuu sanakirjaluettelokustannuksia.

Client nonce välttää tämän ongelman. Protokollasta tulee:

  • palvelin lähettää satunnaisen haasteen c
  • asiakas valitsee ei-käyttäjän n (pitäisi olla erillinen joka kerta)
  • asiakas lähettää n || h (c || n || p)
  • palvelin laskee uudelleen h (c || n || p) (käyttämällä p tietokannastaan) ja tarkistaa, vastaako tämä arvo asiakkaan lähettämiä tietoja.

Koska asiakas sisältää uuden satunnaisarvon ("nonce") hash-funktion syötteeseen jokaiselle istunnolle, hash-funktion syöttö on erilainen joka kerta, vaikka hyökkääjä voi valita haasteen. Tämä voittaa ennalta lasketut (sateenkaaren) taulukot ja palauttaa suunnitellun suojaustason.

Ainutlaatuisen noncen raaka emulointi on käyttäjänimi. Kaksi erillistä käyttäjää samassa järjestelmässä saa erilliset nimet. Käyttäjä kuitenkin säilyttää nimensä, kun hän vaihtaa salasanansa. ja kahdella erillisellä käyttäjällä voi olla sama nimi kahdessa erillisessä järjestelmässä (esim. jokaisella Unixin kaltaisella järjestelmällä on "root" -käyttäjä). Joten käyttäjänimi ei ole hyvä nonce (mutta se on silti parempi kuin ettei sillä ole lainkaan asiakaspalvelua).

Yhteenvetona voidaan todeta, että asiakas nonce tarkoittaa asiakkaan suojaamista uusintahyökkäykseltä palvelin "on itse asiassa hyökkääjä, joka lähettää saman haasteen jokaiselle asiakkaalle, jota hän haluaa hyökätä". Tätä ei tarvita, jos haaste suoritetaan kanavalla, joka sisältää vahvan palvelimen todennuksen (kuten SSL). Salasanan todennettu avaintenvaihto ovat kehittyneitä protokollia, jotka varmistavat keskinäisen salasanapohjaisen todennuksen asiakkaan ja palvelimen välillä ilman, että tarvitsevat a priori luottamusta ("juurivarmenteet", kun SSL-asiakas todentaa SSL-palvelimen varmenteen) ja suojaavat. aktiivisia ja passiivisia hyökkääjiä vastaan ​​(mukaan lukien kahden viikon pituinen klusterihyökkäys yhdelle salasanalle, joten se on ehdottomasti parempi kuin yllä oleva protokolla, ei tai ei).

Vau. Kiitos! Toivon voivani äänestää uudestaan.
Tiivistetodennuksessa palvelin lähettää noncen ja sitten asiakas lähettää saman nonce: n takaisin. Minusta näyttää siltä, ​​että asiakaskone on todella hyödyllinen vain silloin, kun palvelin ottaa sen, mitä asiakas sanoo olevan nimellisarvona, sen sijaan, että palvelin itse tuotti? Jos HTTP-yhteys pysyi hengissä, minusta tuntuu, että palvelin voisi tietää, mikä se juuri lähetetty sisältö oli.
@paynes_bay Tilattomuus on usein toivottava ominaisuus HTTP: tä käytettäessä, erityisesti skaalautuvuuden ja korkean käytettävyyden vuoksi. Jos ei lähetetä palautetta palvelimelle, Digest-todennus olisi tilallinen.
Uteliaisuudesta - onko asiakkaan tärkeä osa sitä, että palvelin seuraa ja tallentaa jokaisen sellaisen, että todennus hylätään, kun myös asiakaspalvelua käytetään uudelleen?
Pelkästään selväksi: Client nonce on tarkoitettu erityisesti silloin, kun hyökkääjä on palvelin, eikö?Muuten, vaikka olisin suojatun kanavan yli, joku / siepaaja edelleen yksinkertaisesti välittää pyynnön uudelleen (toisto) tarvitsematta purkaa sitä.Mutta tällaisissa hyökkäyksissä käytämme muita mekanismeja, kuten pyyntölaskuri (per nonce) ja vastaavat.
#2
+7
Bosh
2011-04-10 11:12:22 UTC
view on stackexchange narkive permalink

Saanen yrittää vastata kysymyksiisi: "Oletetaan hetkeksi, että hyökkääjä ei halua osallistua välimies-hyökkäykseen ja haluaa palauttaa todennuksen yksityiskohdat. cnonce tarjota lisäsuojaa? "

Tyypillisesti asiakas ei vain sisällytä pyyntöön ei-tilaa, mutta allekirjoittaa koko pyynnön, mukaan lukien nonce . Tämä tarkoittaa, että vaikka hyökkääjä siepaisikin viestin asiakkaan ja palvelimen välillä:

  1. Uudelleentoistohyökkäys ei toimi (koska palvelin seuraa asiakaskoneita).
  2. Hyökkääjä ei voi vain luoda uutta viestiä uusi asiakasohjelmalla, koska se ei osaa allekirjoittaa uutta viestiä asianmukaisesti (ts. siltä puuttuu asiakkaan salaisuus tai yksityinen avain).
Eikö asiakkaan tuottama nonce rikkoo haaste-vastausmallia? Mitä vaikutusta sillä on? Cnonce voi vahvistaa, että viestiä ei ole nähty aiemmin, mutta ei siitä, että se olisi tuore. Toisin sanoen se avaa järjestelmän ajoituksille hyökkäyksille, joissa hyökkääjä sieppaa asiakkaiden vastauksen, kieltää palvelun ja käyttää vastausta uudelleen.
Asiakas voi sisällyttää vanhenemisajan. Jos palvelin vastaanottaa viestin (allekirjoitettuun) viestiin sisältyvän vanhentumisen jälkeen, se kohtelee viestiä samalla tavalla kuin jos allekirjoitus olisi virheellinen.
@Justice tämä tuo mukanaan synkronointiaikaa ja niin edelleen. Mistä palvelin tietää, mikä aika on asiakkaalla? Tämä olisi helppo huijata.
Väärentäjä ei voi väärentää vanhentumisaikaa, koska vanhentumisaika on osa allekirjoitettavaa viestiä. HTTP: ssä kellosynkronointia ei vaadita, koska asiakas saa aina kellonajat palvelimelta; Vaikka asiakas voi laskea keston oman kellonsa mittaamisen perusteella, se lisää aina kyseisen keston palvelimen kellonaikaan saadakseen uuden kellonajan.
@Justice Tajusin juuri, että palvelimen ajan käyttö ja sen muokkaaminen asiakkaan ajan mukaan on oikeastaan ​​vain yksi tapa toteuttaa palvelin nonce. Joten tosiasiassa ajan käyttäminen tällä tavalla on yksinkertaisesti vain palvelimen käyttäminen.
Luulen, että "allekirjoittaminen" viittaa jonkinlaiseen aitouden leimaan (kuten HMAC tai sth).
#3
+1
OJ
2011-04-10 08:50:24 UTC
view on stackexchange narkive permalink

Luulen, että hyvä idea olisi lukea kuinka nonce-arvoa käytetään esimerkiksi Oauthissa. Lyhyesti sanottuna, kun OAuthia käyttävä sovellus tekee pyynnön OAuthin tukemalle palvelulle, pyynnössä on oltava joukko kenttiä, joista kaksi on aikaleima ja ei. Lomakkeen tarkoitus on ilmeinen: se osoittaa ajanjakson, jolloin viesti lähetettiin, jotta palvelin voi paremmin arvata, onko viesti vanhentunut vai ei. Jälkimmäinen on tietysti joukko satunnaisia ​​merkkejä / tavuja.

Kun koko OAuth-otsikko on hajautettu kuluttajasalaisuuteen, molemmat nämä kentät sisältyvät. Sitten on allekirjoitus, jonka se on liittänyt pyyntöön (olipa kyse sitten kyselyparametreista tai HTTP-otsikoista) ja lähetetty palvelimelle. Pyynnön todellinen runko on ei hajautettu.

OAuth-palvelimen tulisi seurata tietyn asiakkaan edellistä N ei-arvoa -joukkoa varmista, että niitä ei käytetä uudelleen. Ottaen huomioon, että viestin runko voi muuttua (sillä ei ole mitään vaikutusta hashiin), on tärkeää, että sinulla on jotain muuta, joka muuttuu (ts. Nonce) varmistaaksesi, että pyynnöt ovat ainutlaatuisia. Kun otetaan huomioon HTTP: n avoin / pelkkätekstinen luonne, tämä on melko tärkeää.

Auttaako tämä ollenkaan selventämään sen tarkoitusta? (toivottavasti niin :)).

Eikö OAuth rikkoa haaste-vastausmallia saamalla kuluttajan luomaan nonce? Eikö tämä ole huono? Käyttäjäkysymys voi vahvistaa, että viestiä ei ole nähty aiemmin, mutta ei siitä, että se olisi tuore. Toisin sanoen se avaa järjestelmän ajoituksille hyökkäyksille, joissa hyökkääjä sieppaa asiakkaiden vastauksen, kieltää palvelun ja käyttää vastausta uudelleen.
#4
+1
paynes_bay
2011-07-11 04:33:00 UTC
view on stackexchange narkive permalink

RFC 2617: n mukaan cnonce - ja nc -parametrit suojaavat valittuja selkokielisiä hyökkäyksiä vastaan. Kuinka tämä suojaa tällaisilta hyökkäyksiltä?

Jos Eve muuttaa sitä, mitä palvelin lähettää asiakkaalle, mitä Eve on saanut? Eve ei voi luoda h (salasana || nonce) -kohtaa h (salasana || fake_nonce) -kohdasta, ja teoriassa näyttää siltä, ​​että palvelimen ei pitäisi hyväksyä h (salasana || fake_nonce) joka tapauksessa, koska palvelimen on tiedettävä, mitä noncea se on annettu ja mitä noncea ei.

Jos kysyt kysymystä, sen pitäisi todennäköisesti sisältyä erilliseen kysymykseen eikä vastaukseen tässä.
Se on suunnilleen sama kysymys, joka täällä kysytään. Haluan tietää, mikä on asiakaspalvelun käyttö. RFC2617 tarjoaa vastauksen, mutta tällä vastauksella ei ole minulle paljon järkeä. Thomas Pornin antoi vastauksen myös, mutta hänen vastauksellaan ei ole minulle paljon järkeä vastaukseni mukaan.
@paynes_bay tervetuloa sivustolle! Lue [UKK] - vastaukset ovat kysymykseen * vastaamista varten. Jos etsit selvitystä toisesta vastauksesta, kommentit toimivat. Jos haluat lisätietoja, joita alkuperäinen kysymys ei kata, kysy toiselta!


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