Kysymys:
Miksi jotkut ihmiset todella vihaavat tietoturvaa asiakaspuolen kautta?
Incognito
2011-05-18 18:52:17 UTC
view on stackexchange narkive permalink

Katsotaan esimerkiksi verkkosivuston yhteistä kirjautumisjärjestelmää.

  1. HTTPS-yhteys on muodostettu
  2. Käyttäjä lähettää tunnistetiedot POST: n kautta
  3. Palvelin -puolikoodi hajauttaa salasanan ja näyttää, vastaako se käyttäjänimeä.
  4. Istunto on alustettu, ja avain voidaan antaa kirjautumiseen uudelleen ilman salasanoja ("muista minut")
  5. ol >

    Tämä on yleensä nykytila, jossa kaikki salasanat lasketaan palvelimella. Mutta jos teemme seuraavan asiakaspuolen, sitä pidetään huonona käytäntönä:

    1. HTTPS-yhteys muodostetaan
    2. JavaScript laskee hashin (voi pyytää tiettyä käyttäjän suolaa)
    3. Skripti lähettää AJAX-käyttäjän / hash-arvot
    4. Palvelinpuolen koodi näyttää, vastaavatko salasanan hash ja käyttäjänimi.
    5. Istunto alustetaan ja avain saattaa myönnetään kirjautumaan uudelleen ilman salasanoja ("muista minut")

    Voiko joku selittää, miksi tätä muuta menetelmää pidetään huonona käytäntönä tehdä se CS: n sijaan SS: n sijaan? Molemmat lähettävät SSL: n kautta, molemmat luovat suojatun hashin, ja molempia todennuksia on pidettävä luotettavina hyvin kirjoitetulla koodilla. Molemmat ovat alttiita XSS: lle ja muulle huonolle suunnittelulle.

Tämä voi auttaa http://stackoverflow.com/questions/1380168/does-it-make-security-sense-to-hash-password-on-client-end
Oletin aina, että ainakin osa syystä oli saavutettavissa. Toinen esimerkkisi perustuu javascriptiin, eikä se toimisi asiakkaille ilman js-tukea. Olen kuitenkin kiinnostunut selvittämään, miksi tämä olisi huono idea * turvallisuus * -näkökulmasta. Ainakin HTTP: n kautta oletan, että tämä lisäisi ainakin jonkin verran "suojausta", koska istunnon vaarantaminen ei tuota välittömästi käyttäjän salasanaa (jota he todennäköisesti käyttävät muille sivustoille).
Annan vastausten käsitellä yleistä kysymystä, mutta jotta molemmat ehdotuksesi olisivat edes samanlaiset (ts. Joku palvelimella ei näe asiakkaan todennustunnusta), palvelinpuolen vaiheen 3 on oltava myös asiakaspuolen vaihe 4. Lisäksi "hajautus" on virheellinen vaiheessa SS3, uudessa CS4: ssä, ja hyvin todennäköisesti myös CS2: ssa; käyttää tavallista salasanan tiivistystoimintoa vaaditaan - BCrypt, SCrypt tai PBKDF2 niin suurella työtekijällä / iterointiluvulla kuin mahdollista huippukuormituksella. Lisäksi suolan on kaikissa tapauksissa oltava satunnaisia ​​ja pitkiä (8-16 tavua).
Tällä olisi sama vaikutus kuin salasanojen tallentamisella selkeään tekstiin.
Yhdeksän vastused:
#1
+33
rook
2011-05-18 23:32:49 UTC
view on stackexchange narkive permalink

Kuvaamasi sisältö ei paranna järjestelmän turvallisuutta. Se ei ole mielipiteen tai tunteen asia, turvallisuus ei vain toimi tällä tavalla. Esimerkissä hash (suola + salasana) on nyt salasanasi. Jos se ei ollut yli https, hyökkääjä voisi vain toistaa kyseisen arvon. Et myöskään käsitellyt owasp a9 eli "firesheep" -tyyppisiä hyökkäyksiä.

OTOH, jos hajautit (suola + salasana + nonce), siitä tulee * yhden kerran * salasana (ei toistoa); se on kuitenkin tavallaan turhaa HTTPS: n kautta (puhumattakaan siitä, että selain toteuttaa sen jo HTTP Digest Auth).
@Piskvor itse asiassa SMB-protokolla teki jotain hyvin samanlaista. CVE annettiin, koska ei toistettu parin tuhannen yrityksen jälkeen. Jos haistit langan etsimällä Noncea, voit yrittää jatkaa sisäänkirjautumisen toistamista, kunnes palvelin käyttää noncea uudelleen.
No, jos käytät sitä uudelleen, se on tuskin enää * ei, eikö niin? ; o) osoittaa vain, että turvallisuus on vaikeaa.
+1 hyvästä vastauksesta ja näyttää minulle omaa. Voi olla hyödyllistä selittää uhkia vähemmän teknisille ihmisille.
@rook, Näen paljon vastauksiasi, ja ihmettelen, mikä on sinun ikäsi?
@Pacerier Olen kaksikymppisenä, ja aloin julkaista hyökkäyksiä ensimmäisen kerran teini-ikäisenä.
@rook, Ic, opiskeletko compsci?
@Pacerier Mielestäni hakkeri on vain ammattitaitoisen insinöörin ansaitsema titteli. Yksikään ohjelmoija ei halua kirjoittaa epävarmaa koodia, ja ollaksesi menestyvä tunkeutumistestaaja, sinun on ymmärrettävä, miten sovellus toimii paremmin kuin insinöörit, jotka kirjoittivat sen. Compsci-opiskelu ja sovellussuunnittelun teorioiden ymmärtäminen on vasta ensimmäinen askel.
@rook, Ic, joten tutkit tunkeutumistestausta.
@Pacerier Olen tunkeutumistesti, tutkin kuinka ohjelmisto rakennetaan ja miten se epäonnistuu.
#2
+16
bethlakshmi
2011-05-18 20:46:11 UTC
view on stackexchange narkive permalink

Se liittyy sen suojaamisen yleiseen laajuuteen. Jos kehität palvelinpuolen sovellusta, yrität suojata palvelinta sekä käyttäjältä että hänen asiakasjärjestelmältä. Käyttäjän järjestelmän (ts. Asiakkaan) suorittaminen turvallisuustyösi puolestasi ei todellakaan auta palvelinta pysymään suojattuna. Yleensä oletetaan, että kun asiakas tekee jotain, vaikka se toimisikin palvelimen käskystä (palvelimen toimittaman JavaScriptiä ajatellen), asiakkaaseen ei luoteta luontaisesti, koska hakkeri voi ottaa hallinnan asiakaspuolelta sovellus ja lähetä syöte erillään JavaScriptistä.

Palvelin hajauttaa salasanan estääkseen salasanasäilön paljastamisesta johtuvat ongelmat. Jos hyökkääjä saa haltuunsa salasanan hajautusasetukset, niiden pitäisi olla mahdotonta käyttää niitä lähettämällä salasanat hakkeroidusta asiakaskoneesta - koska palvelin tekee omaa hajautustaan. Jos palvelin delegoi tämä työ asiakkaalle, palvelin delegoi myös suojaustoiminnon.

Kaikki riippuu siitä, miten määrität suojauksen rajan. Jos sinulla on syytä uskoa, että asiakaskoneella ei ole minkäänlaista uhkaa ja että mitään asiakasjärjestelmää ei voida koskaan hakkeroida, niin tämä asia katoaa ... mutta en tiedä yhtään verkkojärjestelmää, joka voisi varmasti esittää tämän vaatimuksen .

Sinulla voi olla kaksi kerrosta hajautusta lieventääkseen toisessa kappaleessa kuvattua ongelmaa, kuten HTTP Digest tekee (2. hashilla olevan noncen kanssa). Ensimmäinen HA1 on tallennettu palvelimelle ja asiakas tietää kuinka se lasketaan (kun käyttäjä syöttää salasanan), ja asiakas pystyy myös laskemaan HA2. Hajautus asiakkaan puolella ei todellakaan ole ongelma (palvelimen on tietysti tarkistettava, mitä asiakas lähettää itse laskemaansa hajautusta vastaan).
Sanoisin myös, että palvelin hajauttaa salasanat ensinnäkin käyttäjän salasanojen suojaamiseksi (ja vain sen seurauksena suojaa itseään, koska hyvä asiakassuoja hyödyttää koko järjestelmää). Jos tallennettu salasana on vuotanut, se on yleensä merkki palvelimen ongelmasta ensin. Hajautuslaskun laskeminen tarkistettavaksi asiakkaalla tai palvelimella ei todellakaan tee mitään eroa tässä (edellyttäen, että palvelin tarkistaa tuloksen sen mukaan, mitä se luottaa: tietysti oman hajautetun salasanansa).
@Bruno - Ensimmäinen kommentti - Pelkäänpä, etten saa sitä, mitä aiot täällä ajaa ... ehdotuksessasi on paljon sekoitusta, enkä näe sen arvoa - jos palvelimen on laskea uudelleen, mitä asiakas tekee ei-hajautetun datan perusteella, miksi asiakas on laatinut hajautuksen ollenkaan ?; toinen kommentti - olen samaa mieltä, mutta olen ohittanut tämän, koska kysymyksen tarkoitus näytti olevan - miksi ei delegoida asiakkaan kaltaisia ​​asioita, kuten hajautus.
#3
+14
Rory Alsop
2011-05-18 20:45:12 UTC
view on stackexchange narkive permalink

Perimmäinen syy ei ole viha ... se on epävarmuutta. Yleisenä periaatteena on luottaa mihinkään, jota et voi hallita. Jos käyttäjä todentaa sovelluksen, et voi luottaa siihen, ellet ole antanut kannettavaa tietokonetta käyttäjälle, määrittänyt sen hallintalaitteet ja sen ympäristön ohjaimet, johon se istuu.

Perinteinen tapa Tarkasteltaessa se on, että jos hyökkääjällä on fyysinen pääsy tietokoneeseen, he voivat tehdä mitä haluavat.

Yksinkertaisella selaimella, joka vain asettaa salatun linkin, on hyvin vähän vaarantamista, paksumpi asiakas, mikä tahansa toiminnallisuuden asiakaspuoli saattaa vaarantua.

#4
+10
Brendan Long
2011-05-18 23:40:24 UTC
view on stackexchange narkive permalink

Jos lasket hash-asiakaskohdetta, lisäät riskin, että hyökkääjä tarvitsee kirjautumiseen vain käyttäjän salasanan hash-todellisen salasanan. Voit todennäköisesti kiertää sen lähettämällä nonce-salasanan hajauttamisen (pohjimmiltaan istuntokohtainen suola), mutta sitten sinun on silti hajautettava se myös palvelimen puolella, joten miksi vaivautua tekemään sitä asiakkaalla ollenkaan ?

#5
+8
Bruno
2011-05-18 19:15:23 UTC
view on stackexchange narkive permalink

En ole varma, vihaavatko ihmiset asiakkaan puolella kuvaamiasi mekanismeja.

Mielestäni tämä liittyy enemmän vanhoihin käytäntöihin ja asiakkaan epätasaiseen tukeen.

Ensinnäkin tarvitset JavaScriptin tämän toteuttamiseksi, jos haluat tehdä sen lomakepohjaisen todennuksen avulla. HTTP Digest tarjoaa jotain samanlaista luonnostaan, ja useimmat selaimet tukevat sitä (mukaan lukien selaimet, joilla ei ole JavaScript-tukea), mutta se ei "näytä hyvältä" eikä sitä voida integroida kovin hyvin verkkosivuston yleiseen brändäykseen. Ollakseni oikeudenmukainen, jos sinulla on tunnistettavissa oleva tuotemerkki, johon aiot kirjoittaa salasanasi, voi olla hyvä asia myös turvallisuusnäkökulmasta. Lisäksi yksi suurimmista HTTP Digest -toteutusten puutteista selaimissa on, että ponnahdusikkunat eivät näytä kovin erilaisilta kuin HTTP Basicia käyttävät, mikä ei tarjoa mitään suojaa.

Toiseksi, kuten sikäli kuin olen tietoinen siitä, JavaScript-salaustoimintojen tuki vaihtelee selaimesta toiseen. Joskus voi olla siedettävää olla riittämätön tuki tietyille selainten ominaisuuksille, sisäänkirjautuminen on melko perustavaa laatua olevaa asiaa, jota et koskaan halua rikkoa.

Lopuksi sinun on silti luotettava koodiin palvelimen lähettämä, joten tässä ei ole mitään hyötyä, jos kirjaudut kuitenkin sisään HTTPS: n kautta. Kun lähetät salasanasi HTTPS: n kautta, annat sen tosiasiallisesti palvelimelle ja luotat palvelimeen käsittelemään sitä oikein. Jos et luota palvelimeen tarpeeksi antamaan sille salasanasi, ei ole mitään syytä luottaa siihen JavaScriptillä, jonka se lähettää sinulle todennuksen suorittamiseen.

+ 1-merkintä "jos et luota palvelimeen". Jos palvelin tietää hash-koodin ja voit vain kirjautua sisään hashilla, hashista tulee salasana tehokkaasti.
@StephenPaulger, hashista / salasanasta, kyllä. Ellet käytä kertakirjautumista tai asiakasvarmenteen todennusta, todennus on puolueellista kohti sitä, että palvelin kutsuu laukauksia sen mukaan, minkä salasanan pitäisi olla (työnnetään äärimmäisyyksiin, se voi jopa nollata oman salasanasi ja lukita sinut palvelustaan) . Tässä yhteydessä salasanan "omistajuus" jaetaan käyttäjän ja palvelimen välillä joka tapauksessa.
#6
+6
Stephen Paulger
2011-05-18 19:12:34 UTC
view on stackexchange narkive permalink

Esimerkissäsi on ainakin yksi liiketoiminnallinen syy ja yksi tietoturvasyy, jonka vuoksi sitä ei välttämättä tehdä niin.

Liiketoiminnan syy

  • Käyttäjä vaatii Javascriptia. Tämä ei ole välttämättä aina käytössä.

Suojaussyy

  • Salasanat tallennetaan tavallisesti suolalla. Tarvitset joko jatkuvan suolan, mikä tekisi siitä vähemmän hyödyllisen; jaa tietyn käyttäjän suola, mikä lisää komplikaatiota ja taas tekee siitä vähemmän hyödyllisen (vaikkakaan siinä määrin, että suolalla on vakio); tai kenties käyttäjätunnuspohjainen suola.

Kaikki järjestelmät eivät vältä käyttämästäsi järjestelmää, kuten kuvailit, Lastpass laskee hajautukset asiakaspuolella (kuvattu Security Now -podcastissa ( transkriptio)).

Tallennuksen suhteen voit tallentaa HA1-hash-vastaavuuden HTTP-digestiin (joka tosiasiassa käyttää käyttäjätunnussuolaa).
#7
+3
Marcin
2011-05-26 17:57:02 UTC
view on stackexchange narkive permalink

Tietoturvan suorittamisella asiakkaan puolella on yksi valtava ongelma: oletat, että asiakas käyttäytyy hyvin. Entä jos eivät? Joten annat heidän laskea hash ... nyt sait ihmiset käyttämään ennalta laskettuja hash-taulukoita, jotka paukuttavat palvelimesi huippunopeasti ja ottavat esiin yhden hajautuksen tärkeimmistä eduista: heidän hitautensa. Jos et tee niin, mutta palvelimen on tehtävä hajautus asiakkaalle, voit pyytää asiakasta pyytämään tuhansia merkkijonoja hajauttamaan, hidastamaan palvelinta ... Joten pohjimmiltaan se on "poista myrkky". Sinun on valittava vastaus toimialakohtaisen tiedon perusteella: luotatko käyttäjiisi? Onko se päin Internetiin? Jos näin on, et todennäköisesti halua luottaa käyttäjiin.

Protokollan analysoinnin oppiminen on todennäköisesti paras tapa ymmärtää, miksi et halua antaa asiakkaiden tehdä paljon turvallisuuteen liittyviä asioita. Toistohyökkäykset, ennakkolaskuhyökkäykset, ne kaikki tapahtuvat, koska annat asiakkaille liikaa vapautta, liikaa valinnanvaraa. Lue Needham-Schroeder-Lowe -protokollasta, miten se syntyi, kuinka he löysivät hyökkäyksen ja mikä on korjaus. Se on hieno osoitus siitä, miten haluat rakentaa protokollan, joka on suojattu haittaohjelmilta .

#8
+1
user9651
2012-05-15 17:55:25 UTC
view on stackexchange narkive permalink

Vastaamiseen kysymykseesi riittää, kun ymmärrät salasanojen hajauttamisen tarkoituksen.

Salasanojen hajautuksen syy on tallentaa johdannainen todellisen salasanan sijaan. Tämä estää mallorya kirjautumasta palvelimeen Alice-nimisenä, vaikka hän olisi vaarantanut palvelimen tietokannan (melko yleinen ongelma). Kuulet aina luottokortin numeroiden paljastamisesta eikä salasanoista, koska hajautetut salasanat eivät ole tällä tavoin haavoittuvia.

Tämä estää myös mallorya löytämästä salasanaa, jota Alice saattaa käyttää muilla verkkosivustoilla / ohjelmistoissa.

Voidaan huomata, vaikka ei ole tarpeen vastata kysymykseesi, että suolaa käytetään palvelimissa hajautettaessa. Tämä tehdään sateenkaaritaulukkohyökkäysten estämiseksi, koska satunnaiset salasanat voidaan toistaa ja hajauttaa ne yleisesti käytetyillä hajautusalgoritmeilla niiden tallentamiseksi taulukkoon. Mallory voisi nyt hakea salasanat uudelleen hakemalla taulukon. Tämä on yleinen tekniikka käyttöjärjestelmän salasanojen palauttamiseksi. (ainakin Windows ei käytä / ei käyttänyt suolaa). Suolan ydin on se, että se on ainutlaatuinen asennusta / verkkosivustoa kohden sekä salainen (se tallennetaan yleensä php / config-tiedostoihin eikä tietokantaan muiden salasanojen kanssa).

Päällä asiakaspuolen turvallisuus. Se, mitä ehdotat, ei todellakaan ole asiakaspuolen suojaus, koska ehdotat vain jättää pois vaihe salasanojen tallentamisesta. Huomaa, että jokainen käyttäjä voi vapaasti käyttää hashia salasanana.

Ymmärrettävä asia on, että sinun on aina turvattava tietyn yhteyden vastaanottavassa päässä (etenkin, mutta ei vain julkisesti saatavilla olevassa palvelussa). . Koska kuka tahansa voi yhdistää verkkopalvelimen, et voi luottaa mihinkään tulevaan. Kaikki asiakkaalle mahdollisesti sattuneet suojaukset on tehtävä, koska jotkut hyökkääjät voivat helposti ohittaa suojauksen.

Huomaa vasta-esimerkkinä, että asiakkaalla on myös suojaus. Kun selain on vastaanottopää , se rajoittaa pääsyn isäntätiedostojärjestelmään esimerkiksi verkkosivustojen komentosarjoille.

#9
+1
Jason Smith
2012-07-12 22:52:20 UTC
view on stackexchange narkive permalink

Anteeksi, että myöhästyimme juhliin ...

Vastaukset ovat kunnossa, että käyttämällä vastaanotettua tiivistettä sellaisenaan verrattaessa tietokantaan, olet tehnyt hashista uuden "salasanan" . Jos kuitenkin lisäät satunnaisen haasteen (alias "nonce"), lähetettyä hajautusta ei voida enää käyttää uudena salasanana.

Olen täysin eri mieltä vastauksista, jotka yleistävät, että asiakaspuolen suojaus on huono asia. Käytämme asiakaspuolen hajautusta (käyttäen suolaa ja noncea) korkean profiilin verkkosivustolla vuosien ajan. Pääasiassa kahdesta syystä:

  1. Vältä selkokielisiä salasanoja sattumasta vahingossa palvelinlokeihin
  2. Estä järjestelmänvalvojien "vaeltavia silmiä" oppimasta salasanoja
  3. ol >

    Asiakaspuolen hajautusta käyttämällä emme koskaan altistu käyttäjien selkokieliselle salasanalle, ja olemme siten vähentäneet vastuumme.

    Yritämme parhaillaan suunnitella avaimen venyttämistä järjestelmään, mikä osoittautuu olla hieman kovempi. Katso Haastava haaste: asiakaspuolen salasanan hajautus ja palvelinpuolen salasanan vahvistus

Voitteko kuvata käytetyn protokollan?


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