Palvelimen ja käyttäjänimen käyttäminen suolana (tai sen hashina) ei ole ihanteellista, koska se johtaa suolan uudelleenkäyttöön, kun vaihdat salasanasi (koska pidät nimesi ja puhut silti saman palvelimen kanssa). Toinen menetelmä on saada suola palvelimelta valmisteluvaiheena; tämä tarkoittaa ylimääräistä asiakas-palvelin edestakaista lentoa ja tarkoittaa myös sitä, että palvelimen on vaikeampi piilottaa onko olemassa tietty käyttäjänimi vai ei (mutta sillä ei ole merkitystä käytännössä).

Mitä description on hyvin tunnettu idea, jota yleensä kutsutaan palvelimen helpotukseksi ja jota voidaan soveltaa mihin tahansa salasanan tiivistystoimintoon juuri samalla tavalla kuin kuvaat:

• Asiakas saa ( tai laskee) suolan.
• Asiakas laskee hitaasti suolatun hash-arvon V ja lähettää sen salasanana.
• Palvelin tallentaa h (V) jollekin nopealle hajautusfunktiolle h ja käyttää sitä vahvistaakseen asiakkaan V arvon.

Tämä on turvallinen. Tärkein haittapuoli on, että hidas hajautus tapahtuu asiakkaan nopeudella, joten iteraatioiden määrää voidaan joutua pienentämään, mahdollisesti huomattavasti, jos asiakas on laskennallisesti heikko - kuten kaikessa, joka liittyy Javascriptiin. Jos järjestelmän on toimittava selaimen kanssa ei-niin äskettäisessä älypuhelimessa, iterointiluvun on oltava 10-100 kertaa pienempi kuin mitä palvelimella voitaisiin tehdä, mikä merkitsee vastaavaa vähennystä raakaa voimaa vastaan ​​(in jos hyökkääjä varastaa palvelimelle tallennetut hajautusarvot).

Joten se on kompromissi: koska kiireinen palvelin purkaa työtä asiakkailla, se voi käyttää suurempaa iterointilukua hukkumatta itse kuorman alla; mutta koska asiakkaat ovat heikkoja, iteraatiomäärää on alennettava, yleensä paljon enemmän kuin purkamisen ansiosta; tämä tarkoittaa, että rakentaminen ei ole vaivan arvoista. Yleensä.

Tietenkin, jos asiakkaat ovat laskennallisesti vahvoja, esim. tämä on pelikoneen natiivikoodisovellus, palvelimen helpotus on hyvä idea ja näyttää siltä, ​​kuin kuvaat sitä.

Toinen mahdollisuus on siirtää työ toiselle, kolmannen osapuolen järjestelmälle, esim muut asiakkaat (jo yhteydessä): tämä voidaan tehdä turvallisesti jos hash-toiminto sisältää tarvittavat matemaattiset rakenteet. Tällainen purkaminen tunnetaan nimellä delegointi . Tietojeni mukaan delegointia tarjoaa vain yksi salasanan hajautusfunktio, nimeltään Makwa (katso erittely), yksi nykyisen salasanan huutokilpailun ehdokkaista..

I think the biggest concern about this approach is that it moves a security procedure you've determined is important off of your servers and on to the web browsers of users. While normally everything should work as expected you have no real way to verify that the password was actually hashed with bcrypt before it is sent to you. So if the client-side JavaScript is changed you may still end up with only a SHA256 hash of "123456" on your server.

Sure, you could check the format of data sent from the client to make sure it looks like it was hashed with bcrypt, but you don't know for sure that your desired operation completed.

That's not an ideal security model, but despite that I think the threats to this system are still fairly manageable. And you would be ahead of those sites who either don't hash or hash using plain MD5.