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

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 .

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.

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 ?

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.

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

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 .

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.

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