Olen tässä pohtinut, että kannattaisiko minun toteuttaa sisällönhallintajärjestelmääni (mikä ihana sana) challenge-response-tyylisen kirjautumisen. Joku joka tietää termille suomennoksen, kertokoot sen.
Asiaa tuntemattomille yksinkertainen versio: tällä on tarkoitus estää salasanojen lähettäminen netin yli kirjautumisen yhteydessä raakana. Sen sijaan, kirjautumissivulla käyttäjän täyteyttyä lomake JavaScript-koodi (ei nyt tule muitakaan järkeviä tapoja mieleen) laskee salasanasta hashin, yhdistää sen palvelimelta saatuun "haasteeseen", joka voi olla vaikkapa satunnainen numerosarja, ja laskee yhdistelmästä hashin. Tämän jälkeen palvelimelle lähetetään käyttäjänimi ja tämä hash. Palvelin tietenkin tietää oikean salasanan hashin ja antamansa numerosarjan ja osaa laskea niistä saman yhdistelmän. Jos hashit täsmäävät, kirjautuminen onnistuu. Näin kirjautuminen sujui ilman salasanan välittämistä netin yli.
Nyt mietin, että a) onko esityksessäni asiasta virheitä, en ole tietoturva-asiantuntija b) kannattaako tälläinen toteuttaa. Tässä on toki etunsa, mutta samalla tämä heikentää palvelinpään suojaa. Jos hyökkääjä onnistuu pääsemään tietokantaan käsiksi ja lukemaan sinne tallennetut salasanojen hashit, hän pystyy kirjautumaan suoraan tällä metodilla. Jos käytössä olisi vain se perinteinen tapa, hyökkääjä joutuisi ensin selvittämään hasheja vastaavat salasanat (mikä on hankalampaa, ainakin jos ne on suolattu. Challenge-response-tunnistautumisen yhteydessä salasanojen suolaus ei taida onnistua). Pitäisi siis päättää, että kumpi on hyökkääjälle helpompaa, päästä käsiksi salasanoihin vai kuunnella verkkoa.
Jos joku tietää hashille kivan suomennoksen, sen kertokoot.
JavaScriptin käyttö on suuri ongelma tuossa.
Jos joku pystyy seuraamaan liikennettä palvelimen ja käyttäjän välillä, hän saa siis tietoonsa palvelimen lähettämän haasteen ja lopullisen hashin. Nuo tiedot eivät riitä kirjautumiseen, jos haaste vaihtelee ja on tarpeeksi pitkä. Minä en ole sinua parempi asiantuntija, mutta en löydä virhettä päättelystäsi. Mutta miten palvelin tietää, mikä haaste on kulloinkin käytössä?
Luulen kuitenkin, että huolehdit nyt turhasta. Harva hakkeri murtautuisi palvelimelle tai seuraisi verkkoliikennettä päästäkseen käsiksi sisällönhallintajärjestelmään. Ainakin paljon helpompaa luulisi olevan arvata tai onkia tietoon salasana käyttäjältä itseltään. Ja tälle asialle sivun tekijä taas ei voi mitään. Suosittelen joka tapauksessa perinteistä toteutusta.
Saadakseen salasanat palvelimelta hyökääjän pitää murtautua palvelimellesi. Verkkoa kuunnellakseen hyökkääjän pitää päästä käsiksi johonkin palvelimen asiakaskoneen väliseen koneeseen ja usein taitaa myös riittää, että hyökkääjä pääsee kiinni johonkin palvelimen tai asiakaskoneen kanssa samassa lähiverkossa olevaan koneeseen. Voit myös olettaa, että jos hyökkääjä pystyy hakemaan salasanojen hashit palvelimeltasi pystyy hän myös kuuntelemaan kaikkien käyttäjiesi liikennettä ja saa sitä kautta salasanat. Eli verkon kuunteleminen lienee helpompaa ellet jotenkin onnistu täydellisesti mokaamaan tietokannan tietoturvaa.
Suunnittelmasi käytäntö on ainakin minun mielestäni melko hyvä. Se jättää kuitenkin mahdollisuuden man-in-the-middle hyökkäykselle, mutta tämän mahdollisuutta on aika hankala estää enää tällä protokollatasolla.
Kuten Antti tuossa vihjasikin, haasteen numero pitänee toimittaa käyttäjälle ja sitten takaisin palvelimelle, jotta palvelin tietää mihin haasteeseen tuli vastaus. Tässä taitaa häämöttää jonkinlaisen mahdollisuus DoS-hyökkäyksen, koska joudut serveripäässä pitämään kirjaa haasteista; hyökkääjä ottaa n+1 kertaa yhteyden palvelimeen, jolloin joudutaan generoimaan ja kirjaamaan n+1 haastetta. Hidasta ja mahdollisesti tilaa vievää.
En nyt ole kovin varma kuinka turvallinen tuo pelkästään hasheihin perustuva salaus on. Viime aikoina hashien tietoturva on mennyt roimasti alaspäin ja nykyään on esimerkiksi kohtalaisen helppo löytää syöte joka tuottaa saman hashin kuin tarkasteltava md5 hash. Se, että löydetään syöte, jonka osana on se haasteesta tuleva hashi taitaa kuitenkin vielä olla aika hankala ongelma... Toisaalta tietoturvan pahin vihollinen on käyttäjä, joten luultavssti Antin mainitsemilla keinoilla järjestelmä murtuu helpommin kuin hashejä murtamalla.
Se kannattaako tuollainen suunnittelemasi juttu toteuttaa riippuu ihan siitä kuinka paljon rahaa järjestelmääsi liittyy. Jos tuo on tarkoitettu vain omaan käyttöön eikä oletettu hyökkäys aiheuta monen viikon murheita ja rahallisia menetyksiä, ei tuollaista luultavasti tarvitse tehdä. Jos taas raha liittyy projektiin, kannattaa suosiolla siirtyä käyttämään SSL-salausta ja hankkia virallinen sertifikaatti vaikka se aika lailla kustantaakin.
Onhan tuollaisen toteuttaminen kuitenkin ihan kiva ja opettava projekti ainakin, jos meinaat itse toteuttaa hash-algoritmit javascriptilla.
Challenge-reponsen suomenkielinen termi taisi olla haaste-vaste/vastine.
Hashille olen toisinaan tässä yhteydessä kuullut käytetettävän nimitystä tiiviste.
Tuosta hashien tietoturvasta: Jos se pelottaa, niin kannattaa koittaa miettiä jonkinlainen oma, jota voisi sitten olla vaikeampi selvittää, koska kellään muulla ei ole sitä.
Antti Laaksonen kirjoitti:
Luulen kuitenkin, että huolehdit nyt turhasta. Harva hakkeri murtautuisi palvelimelle tai seuraisi verkkoliikennettä päästäkseen käsiksi sisällönhallintajärjestelmään. Ainakin paljon helpompaa luulisi olevan arvata tai onkia tietoon salasana käyttäjältä itseltään. Ja tälle asialle sivun tekijä taas ei voi mitään. Suosittelen joka tapauksessa perinteistä toteutusta.
En minä varsinaisesti pelkää moista, mutta ihan mielenkiinnosta vuoksi tälläistä pohdin. Eikä tässä jutussa rahaa ole kiinni, mutta ei se estä tekemästä turvallisempaa järjestelmää (minusta on hauskaa pohtia tällläisiä asioita). Käyttäjä on tietenkin aina heikoin leikki, mutta koitan silti tehdä muista lenkeistä mahdollisimman vahvoja.
squid kirjoitti:
Tuosta hashien tietoturvasta: Jos se pelottaa, niin kannattaa koittaa miettiä jonkinlainen oma, jota voisi sitten olla vaikeampi selvittää, koska kellään muulla ei ole sitä.
Tarkoitus on julkaista lähdekoodit, joten tämä ei ehkä ole kovin hyvä idea. Muutenkaan en oikein usko tuollaiseen.
Voipa olla, etten tälläistä tähän yhteyteen toteuta ottaen huomioon kiireen ja rajallisen hyödyn, mutta ehkä huvikseni kuitenkin koodaan asiaan liittyvän koodivinkin tai jotain.
"Haastenumero"n pitää tietenkin olla ip-pohjanen ja samaa voi käyttää vain kerran... eli poistetaan pyyntö vain oikean salasanan kanssa ja ajan myötä. Kannattaa kattoa muilta esimerkkiä
Aihe on jo aika vanha, joten et voi enää vastata siihen.