Haluat, että kohdepalvelin pystyy käyttämään käyttäjänimeä ja salasanaa eikä nuuskijakäyttöistä hyökkääjää. Kohdepalvelimen on siis pystyttävä tekemään jotain, mitä hyökkääjä ei voi. Koska hyökkääjä voi ostaa samanlaisen tietokoneen kuin palvelin, ylimääräisen tehon on oltava jotain, jonka palvelin tietää, mutta ei hyökkääjä.

Hei, tällaista tietoa on : salasana ! Se on asia, eikö niin? Se on todellakin ennalta jaettu avain asiakkaan ja palvelimen välillä.

Salasanat ovat avaintekijöiltä melko ikäviä, koska ihmisen aivot ovat rajalliset. Silti voi työskennellä sen kanssa. Parhaat protokollat ​​ovat salasanan todennettu avaintenvaihto: ne voivat kasvattaa jaetun matalan entropian avaimen (salasanan) jaetuksi korkean entropian avaimeksi, jolla voit tehdä kaikki symmetriset yummy-asiat salaus, joka pitää (lanka) haita poissa. Ja PAKE-protokollat ​​voivat tehdä sen vastustamalla offline -sanakirjahyökkäyksiä ("offline" on tässä tärkeä sana).

Huono uutinen on, että PAKE-protokollat ​​ja yleisemmin kaikki todennusprotokollaa, joka voidaan liittää jälkikäteen vaihdettuihin tietoihin, jotta todennus todella vastustaa aktiivista hyökkääjää, on vaikea saada oikeaan. Yksinkertaisin, mutta silti turvallinen protokolla osoittautuu SSL: ksi SRP: n kanssa (tähän on olemassa RFC). Hyvä uutinen on, että SSL + SRP tarjoaa salasanapohjaisen keskinäisen todennuksen asiakkaan ja palvelimen välillä käyttämällä ei todistusta minkäänlaista (ja kun ihmiset sanovat, etteivät halua käyttää SSL: ää, he yleensä tarkoittavat, että he eivät halua käydä läpi X.509-varmenteita ja rajallista PKI-markkinaa.

Valitettavasti SSL + SRP -tuki ei ole laajaa ( GnuTLS on avoimen lähdekoodin kirjasto, joka tuntee SRP: n ).

jos käytät asiakaspuolen hashia, siitä tulee todellinen sivuston salasana etkä saavuttanut mitään.

Paras tapa on käyttää SSL: ää . Mekanismi on olemassa syystä. Vaihtoehtoiset järjestelmät ovat yleensä joko epävarmoja tai mielettömän monimutkaisia.

Sanoit haluavasi tehdä sen ilman SSL: ää, mutta et antanut mitään syytä tai syytä. Et selittänyt tilannettasi tai sitä, mikä oikeuttaisi välttämään SSL: n. Näin ollen, vaikka haluaisimme antaa sinulle vaihtoehtoisia ehdotuksia, olisi mahdotonta selvittää, vastaavatko ne vaatimuksiasi.

Jos kaikki, mikä sinua kiinnostaa, on käyttäjän todentaminen palvelimelle (ja et välitä myöhempien tietojen salaamisesta), Lamportin Hash olisi helppo toteuttaa, koska Javascriptissa ja PHP / ASP / ssä on jo hash-funktiokirjastoja. ASP.net.

Lamport's Hash on kertaluonteinen salasanamalli, joka toimii seuraavasti (Alice on käyttäjä, Bob on palvelin):

Ensirekisteröinti

Rekisteröityessään Alice lähettää [n, hash ^ n (salasana)] palvelimelle (missä hash ^ n on seurausta salasanan hajauttamisesta, sitten sen hajauttamisesta, sitten hajauttaa tuloksen, ..., n kertaa). Palvelin tallentaa [n, hash ^ n (salasana)] tietokantaan.

Todennus

1. Alice lähettää tunnuksensa (käyttäjätunnuksensa) Bob: "Alice"
2. Bob vastaa sanalla "n"
3. Alice lähettää x = hash ^ {n-1} (salasana) Bobille
4. Bob vertaa hash (x) hänen tietokantaansa tallennetulla tiivistelmällä
   • Jos ne vastaavat, todennus onnistuu ja Bob korvaa [n, hash ^ n (salasana)] luvulla [n-1, x = hash ^ {n- 1} (salasana)]
   • Muuten todennus epäonnistuu ja Bob säilyttää tietokannassa olevan sisällön.

Käytännön näkökohdat

• Haluat todennäköisesti käyttää suolaa salasanalla (Bob voi lähettää suolan # 2).
• Kun n on tarpeeksi pieni, Alice täytyy vaihtaa salasanansa (tai he voivat vain vaihtaa suolaa), ja hänen on lähetettävä [n, hash ^ n (suola + salasana)] uudelleen Bobille
• Valitse n tarpeeksi suuri niin, että uudelleenrekisteröinti ei ole liian usein
• Koska tämä on vain yksisuuntainen todennus (käyttäjä todennetaan palvelimelle, mutta palvelin ei ole todennettu käyttäjälle), man-in-the-middle on mahdollista.

Jos Lamport's Hash ei täytä vaatimuksiasi (esim. tarvitset keskinäisen todennuksen), SRP on luultavasti paras veto, mutta siihen mennessä, kun olet ottanut sen käyttöön Javascriptissa ja PHP / ASP / ASP.netissä, olisit voinut vuokrata palvelimen, joka tukee SSL: ää, mikä on selvästi paras valinta alusta alkaen .

Vastaus on TLS (ei edes SSL) ilman AES: ää salausalgoritmina, koska esimerkiksi TLS: n, AES: n ja WebSocketsin yhdistelmässä on tunnettu ongelma. Kaikki muu (kuten salasanan salaus asiakkaassa javascriptin avulla) on epävarmaa. Sitä ei tietenkään voi lukea suoraan wiresharkilla, mutta javascript voi tulla keskellä olevalta mieheltä. Joten yritä vakuuttaa koulusi? siirtyäksesi TLS-palvelimiin. Tämä on helpoin tapa, eikä se vaadi sovelluskoodin muuttamista.

Jos pystyt suorittamaan JavaScriptiä asiakkaalla, voit määrittää Diffie-Helman-avaimenvaihdon tai haasteen / vastausmekanismin salasanan tiivisteen perusteella (älä tallenna selkokielistä järjestelmään!) todennusprosessi, jossa salattu tunnistetieto palautetaan todennusta varten.

Ne eivät pysäytä aktiivisia MITM-hyökkäyksiä, mutta se estää passiivisia hyökkääjiä haamasta salasanoja.

SSL ei voi olla yhtä rikki kuin selkeät tekstisalasanat. Käytä SSL: ää. Luulen, että Scheierillä on jotain sanottavaa ihmisistä, jotka suunnittelevat omat kryptojärjestelmänsä.

En pidä SSL: stä, koska se on rikki.

Se on melko dramaattinen väite heittää pois ilman mitään selityksiä tai tukevia viitteitä. Tarkoitatko kaikkia SSL-muotoja, mukaan lukien TLS, tai erityisesti SSL v1-3: ta?

Se on paljon parempi kuin monet muut yritetyt ratkaisut ongelmaan.

Ainoa tapa luoda Suojattu tiedonsiirto tapahtuu salauksella - ja selainpohjaiselle asiakkaalle, jos et käytä SSL: n sisäänrakennettua toimintoa, toimitat koodin salauksen toteuttamiseksi (olipa se sitten Javascript, ActiveX, Java, Flash ... ) suojaamattoman yhteyden kautta. Siksi koodi voi vaarantua. Sillä ei ole merkitystä, käytätkö rot13- tai 4096-bittistä avainta PFS-algoritmin kanssa - jos sitä käsittelee suojaamattomasti toimitettu koodi, koodin muokkaaminen salasanan sieppaamiseksi on helppoa.

Jos luulet SSL: n olevan rikki ja korjaa se - se on paljon kannattavampi tapa viettää aikaa.

Ensinnäkin tarkistan, tukeeko palvelin http-todennusta yhteenvetotodennuksella. Voit ehkä ottaa sen käyttöön php: n kautta.

http://www.php.net/manual/en/features.http-auth.php

Se ei ole läheskään yhtä turvallinen kuin SSL, mutta se voi olla yksinkertainen temppu, joka estää luokan ihmisiä pyyhkimästä salasanojasi. Estä suojattava sivuston alue käyttämällä http-todennusta. He näkevät kaiken mitä teet, mutta he eivät saa http-todennussalasanaa. (he saavat kaikki muut salasanat istunnon aikana)