Hei!
En ole ymmärtänyt ihan loppuun asti salasanatiivisteiden suolauksen toteutusta. Joku fiksumpi voisi varmaan selittää.
Salasana on hyvä suolata ennen kuin siitä lasketaan tiiviste. Tämä on selvä. Tiiviste sitten tallennetaan tietokantaan. Mihin se suola laitetaan? Jos suola on käyttäjäkohtainen, niin eikös sekin pidä laittaa tietokantaan talteen? Jos murtaja saa kannan sisällön, niin silloin se saa myös ne suolat ja voi kirjoittaa koodin joka tekee sanakirjahyökkäystä lisäten suolan.
Jos taas käytetään kaikille käyttäjille yhteistä suolaa, niin kovakoodataanko se softaan? Ei tunnu oikein kestävältä ratkaisulta tämäkään.
Suolan idea on estää rainbow-taulujen käyttö, ei tehdä salasanakohtaista sanakirjahyökkäystä olennaisesti vaikeammaksi.
Kannattaa ennemmin käyttää vaikka bcryptiä, jolloin sanakirjahyökkäys on vaikkapa miljoona kertaa hitaampaa. (Eli jos suolattu sha1 tai md5 -tiiviste murtuu 10 sekunnissa, niin bcryptilla voi kestää esim. 10 miljoonaa sekuntia eli melkein neljä kuukautta)
tok kirjoitti:
Jos taas käytetään kaikille käyttäjille yhteistä suolaa, niin kovakoodataanko se softaan? Ei tunnu oikein kestävältä ratkaisulta tämäkään.
Yleensä tuo suola on tallennettu johonkin erilliseen asetustiedostoon vakioksi ja sitten varsinainen softa käyttää tuota vakiota hyödyksi. Näin saadaan hieman joustavampi ratkaisu aikaiseksi kuin suoraan suolan kovakoodaaminen ohjelmakoodiin. Suola on myös helpommin vaihdettavissa muokkaamalla vain tuota asetustiedostoa, eikä tarvitse lähteä muokkailemaan tuota varsinaista softaa.
Grez kirjoitti:
Suolan idea on estää rainbow-taulujen käyttö, ei tehdä salasanakohtaista sanakirjahyökkäystä olennaisesti vaikeammaksi.
Kiitos, tämä selvensi asiaa. Suolaus auttaa siis jos rainbow tablella yritetään selvittää plaintext isosta joukosta tiivisteitä, koska vaatisi järjettömän suuren rainbow tablen kun jokaiseen salasanaehdokkaaseen pitäisi yhdistää eri suola eri käyttäjillä?
Miten hyvin tai huonosti toimisi sellainen suolaus, joka on käyttäjäkohtainen, mutta ei satunnainen? Suola olisi esimerkiksi käyttäjätunnus, sähköpostiosoite, osa/yhdistelmä niistä, tms. Kysymys on järjestelmästä, jossa käyttäjän pitäisi tarvittaessa pystyä laskemaan itse oma tiivisteensä. Eikös tämmöisestä suolauksesta olisi yhtä lailla apua rainbow tableja vastaan?
Triton kirjoitti:
Yleensä tuo suola on tallennettu johonkin erilliseen asetustiedostoon vakioksi ja sitten varsinainen softa käyttää tuota vakiota hyödyksi.
Aina ei kannata tehdä, mitä yleensä tehdään, vaan joskus kannattaa tehdä paremmin. Käyttäjäkohtainen suola on jo selvästi turvallisempi kuin vakio.
Yleensä PHP-skripteissä on myös SQL-injektioaukkoja, joita hakkeri voi käyttää hyödyksi. Suositteletko näitäkin? ;)
tok kirjoitti:
vaatisi järjettömän suuren rainbow tablen
Oikeammin se vaatisi oman rainbow-taulun jokaiselle käytetylle suolalle (eli jokaiselle käyttäjälle), jolloin siis taulusta ei olisi mitään hyötyä. Vastaavasti jos käytössä on aina sama suola, riittäisi yksi taulu koko sivustolle. Ilman suolaa riittää yksi taulu koko maailmalle.
tok kirjoitti:
Miten hyvin tai huonosti toimisi sellainen suolaus, joka on käyttäjäkohtainen, mutta ei satunnainen?
Yhden palvelun tasolla ajatellen toimisi kaiketi ihan yhtä hyvin. Mikset kuitenkin voisi käyttää satunnaista suolaa, jonka käyttäjä näkee muiden käyttäjätietojensa yhteydessä?
tok kirjoitti:
Kysymys on järjestelmästä, jossa käyttäjän pitäisi tarvittaessa pystyä laskemaan itse oma tiivisteensä.
Miksi se pitäisi pystyä laskemaan? Kuulostaa suunnitteluvirheeltä.
Metabolix kirjoitti:
Aina ei kannata tehdä, mitä yleensä tehdään, vaan joskus kannattaa tehdä paremmin.
Siksi ehdotinkin bcryptiä (joka muiden merkittävämpien etujen lisäksi huolehtii myös "suolauksesta" itse)
Metabolix kirjoitti:
Yleensä PHP-skripteissä on myös SQL-injektioaukkoja, joita hakkeri voi käyttää hyödyksi. Suositteletko näitäkin? ;)
Yleensä PHP-skripteissä on myös SQL-injektioaukkoja? Voisitko tarkentaa mitä ajat tällä takaa.
http://fi.wikipedia.org/wiki/SQL-injektio:
SQL-injektiossa hyökkääjä antaa tietokantapalvelimelle SQL-komentoja, joita hänen ei pitäisi pystyä antamaan.
Lebe80 kirjoitti:
Yleensä PHP-skripteissä on myös SQL-injektioaukkoja? Voisitko tarkentaa mitä ajat tällä takaa.
Yritin kyynisesti huomauttaa, että merkittävä osa maailman PHP-skripteistä (ja siten myös netissä salasanaa vaativista sovelluksista) on epätäydellisiä tai suorastaan viallisia, minkä vuoksi kaikkea ei kannata automaattisesti tehdä kuten "yleensä", vaan voi pyrkiä parempaan. Anteeksi, jos ajatukseni oli liian kaukaa haettu tai optimistisemmasta näkemyksestäsi poikkeava.
Lebe80 kirjoitti:
Yleensä PHP-skripteissä on myös SQL-injektioaukkoja? Voisitko tarkentaa mitä ajat tällä takaa.
Taas jättivuoto: 500 000 suomalaista sähköpostiosoitetta
Oletko jo vaihtanut salasanasi? "250 000 salasanaa jo selvitetty"
Taas uusi tietovuoto: 12 053 Netcar.fi:n käyttäjätunnusta ja salasanaa julki
Taas uusi jättisalasanavuoto: 70 000 Helistin.fi:n käyttäjätunnusta ja salasanaa vuoti verkkoon
Edellä siis muutaman viime viikon aikana suomalaisista sivustoista uutisoituja. Taitaa olla enemmänkin. Ja tosiaan lisäksi ne joista ei uutisoida ja ulkomaiset.
Metabolix kirjoitti:
Lebe80 kirjoitti:
Yleensä PHP-skripteissä on myös SQL-injektioaukkoja? Voisitko tarkentaa mitä ajat tällä takaa.
Yritin kyynisesti huomauttaa, että merkittävä osa maailman PHP-skripteistä (ja siten myös netissä salasanaa vaativista sovelluksista) on epätäydellisiä tai suorastaan viallisia, minkä vuoksi kaikkea ei kannata automaattisesti tehdä kuten "yleensä", vaan voi pyrkiä parempaan. Anteeksi, jos ajatukseni oli liian kaukaa haettu tai optimistisemmasta näkemyksestäsi poikkeava.
Omat kokemukseni tämän suolausasian osalta perustuukin lähinnä suhteellisen suurten kehittäjäyhteisöjen valmistamiin PHP-ohjelmistokehyksiin, eikä mihinkään naapurin Pekan bugisiin viritelmiin. Mielestäni on myös typerää verrata SQL-injektioaukkoja asetustiedoston käyttämiseen suolauksessa, kun ensimmäisessä on kuitenkin kyse vahingossa tai tietämättömyyden takia jääneestä tietoturva-aukosta ja jälkimmäisessä taas kysymys selvästä suunnitteluratkaisusta... Kyllä se kuitenkin aina omat riskinsä aiheuttaa, kun tietokantaan joudutaan tallentamaan käyttäjäkohtaisia suoloja. Kun tuonne asetustiedostaan määritellään tarpeeksi pitkä, sekalaisista merkeistä koottu, suola, niin kyllä se vaikeuttaa aika merkittävästi rainbow-taulujen käyttämistä kuin myös salasanan md5-tiivisteen bruteforcettamistakin.
Metabolix kirjoitti:
Yhden palvelun tasolla ajatellen toimisi kaiketi ihan yhtä hyvin. Mikset kuitenkin voisi käyttää satunnaista suolaa, jonka käyttäjä näkee muiden käyttäjätietojensa yhteydessä?
Toki voi käyttää satunnaista suolaa, mutta jos käyttäisi käyttäjän jo tietämää asiaa kuten tunnusta, niin olisi yksi asia vähemmän ilmoitettavaa käyttäjälle. Eihän sillä paljon eroa olisi, tämä oli lähinnä tämmöinen ajatuskoe.
tok kirjoitti:
Kysymys on järjestelmästä, jossa käyttäjän pitäisi tarvittaessa pystyä laskemaan itse oma tiivisteensä.
Metabolix kirjoitti:
Miksi se pitäisi pystyä laskemaan? Kuulostaa suunnitteluvirheeltä.
Järjestelmä ottaa vastaan soap-kutsuja. Client liittää kutsuun varmenteen, joka lasketaan kaavalla MD5(parametri1=arvo1;parametri2=arvo2;...
Triton kirjoitti:
jälkimmäisessä taas kysymys selvästä suunnitteluratkaisusta... Kyllä se kuitenkin aina omat riskinsä aiheuttaa, kun tietokantaan joudutaan tallentamaan käyttäjäkohtaisia suoloja. Kun tuonne asetustiedostaan määritellään tarpeeksi pitkä, sekalaisista merkeistä koottu, suola, niin kyllä se vaikeuttaa aika merkittävästi rainbow-taulujen käyttämistä kuin myös salasanan md5-tiivisteen bruteforcettamistakin.
Toki huonokin suunnitteluratkaisu on selvä suunnitteluratkaisu, ei siinä mitään.
Yksi melko konkreettinen haitta kaikille käyttäjille yhteisestä suolasta on se, että kaikkien saman salasanan omistavien tiiviste on myös sama. Isommassa järjestelmässä ei ole vaikea päätellä että yleisimmät tiivisteet on todennäköisesti yleisimpiä salasanoja ja kohdistaa murtoresurssit näihin.
Triton kirjoitti:
Kyllä se kuitenkin aina omat riskinsä aiheuttaa, kun tietokantaan joudutaan tallentamaan käyttäjäkohtaisia suoloja.
Kuten edellä toteisin, suolauksessa on tärkeää, että suola on käyttäjäkohtainen. Olisiko tuolle absurdille väitteellesi jotain toimivia perusteluja? Se että konffitiedostossa oleva suola jota murtautuja ei saa käsiinsä vaikeuttaa murtamista, ei ole vastaperuste ensinkään - asiat eivät ole toisiaan poissulkevia.
Triton kirjoitti:
Omat kokemukseni tämän suolausasian osalta perustuukin lähinnä suhteellisen suurten kehittäjäyhteisöjen valmistamiin PHP-ohjelmistokehyksiin
Ilmeisesti suuri kehittäjäyhteisö ei siis takaa parhaiden käytäntöjen toteutumista.
tok kirjoitti:
MD5(parametri1=arvo1;parametri2=arvo2;...
;parametriN=arvoN;MD5(salasana)
Yksi haitta toki tietysti on se, että jos jokin saa selville käyttäjän MD5 -tiivisteen esim. tietoturva-aukon avulla, niin hän pystyy esiintymään ko. käyttäjänä tietämättä tämän salasanaa. Itse näkisin tuohon tarkoitukseen paljon parempana julkisen avaimen kryptografian ja miksei vaikka jo valmiiksi tarjolla olevia käyttäjä- ja palvelinsertifikaattimenetelmiä. Aina ei tarvitse keksiä pyörää uudestaan.
Tuosta menetelmästä tulee mieleen, että olet ehkä tutustunut Suomalaisten pankkien verkkomaksupainikkeisiin ja/tai Tupasiin. Se, että suomalaiset pankit käyttävät jotain menetelmää, ei tarkoita, että menetelmä olisi optimaalinen. Käyttäähän pankit edelleen yritysten aineistojen suojaamiseen mm. 56-bittistä DESiä :D
Triton kirjoitti:
Kyllä se kuitenkin aina omat riskinsä aiheuttaa, kun tietokantaan joudutaan tallentamaan käyttäjäkohtaisia suoloja.
Mitä riskejä se mielestäsi aiheuttaa?
tok kirjoitti:
Näettekö tässä protokollassa jotain turvallisuusaukkoja?
Näen protokollassa ainakin kohtuuttomasti purkkaa ja virheen mahdollisuuksia verrattuna siihen, että käytettäisiin yksinkertaisesti jotain RSA:n kaltaista vahvaa salausta.
No tietenkin koko järjestelmän turvallisuus riippuu monista eri osa-alueista, esim. jos sql-injektointia ei ole millään tavalla estetty, niin samalla tavallahan noihin käyttäkohtaisiin suoloihin päästään käsiksi kuin salasanojen md5-tiivisteisiinkin. Ja kyllähän ihan peruslogiikalla pystyy päättelemään, että jos on tiedossa salasanan md5-tiivisteessä käytetty suola, niin kyllähän tuo tiiviste murtuu nopeammin ja helpommin. Tietenkin tässä saattaa olla jokin tekijä, jota en ole osannut ottaa huomioon, mutta näin sen olen ajatellut.
Edelleenkään logiikastasi ei aukea, miten se käyttäjäkohtainen suola lisää riskiä.
Eli siis perustele nyt vielä kansantajuisesti miksi käyttäjäkohtaisen suolan kanssa lasketun tiivisteen murtaminen on helpompaa kuin ilman käyttäjäkohtaista suolaa lasketun tiivisteen. (Minkään muun muuttumatta)
Triton yrittää varmaan vedota siihen, että näissä uutisoiduissa murroissa on saatu (ehkä?) pelkkä tietokanta mutta ei koodia tai asetustiedostoja. Silloin todellakin globaali (hakkerille tuntematon) suola saattaa olla piirun verran parempi kuin käyttäjäkohtainen. Tähän logiikkaan perustuva suunnittelupäätös on aika surullinen, koska se tavallaan velvoittaa tekemään muut osat softasta huonosti, jotta ratkaisua voi sitten perustellusti sanoa oikeaksi. ;D
Jos SQL-injektion mahdollisuutta ei ole, globaalista suolasta ei ole mitään lisähyötyä suhteessa käyttäjäkohtaiseen suolaan. Sen sijaan käyttäjäkohtaisesta on aina hyötyä. Sitä voi sitten jokainen omalla kohdallaan ohjelmointitaitojensa ja itsevarmuutensa (tai työnantajana budjettinsa ja imagonsa) valossa punnita.
Tietysti on mahdollista käyttää sekä käyttäjäkohtaista että globaalia suolaa, jolloin saa molempien edut ja vähän lisää sotkua koodiin.
Metabolix kirjoitti:
Triton yrittää varmaan vedota siihen, että näissä uutisoiduissa murroissa on saatu (ehkä?) pelkkä tietokanta mutta ei koodia tai asetustiedostoja. Silloin todellakin globaali (hakkerille tuntematon) suola saattaa olla piirun verran parempi kuin käyttäjäkohtainen.
No kuten mä olen tässä jo muutaman viestin ajan sanoa, niin tuossa perustelussa ei ole päätä eikä häntää, koska käyttäjäkohtaisen suolan käyttö ei estä globaalin suolan samanaikaista käyttöä (kuten itsekin totesit). Eihän nää perustietojärjestelmien koodaukset nyt mitään raketin rakentamista ole, itsekin olen tehnyt joskus 15 vuotta sitten ekan laajaan käyttöön tulleen järjestelmän, jossa oli sekä globaali että käyttäjäkohtainen suola.
Jos järjestelmä on niin huono, että kannan saa dumpattua, niin en todellakaan panisi kaikkia pelimerkkejä sen varaan, että konffitiedostoakin ei saa luettua.
Ilman käyttäjäkohtaista suolaa (jos mahdollien järjestelmänlaajuinen suola on selvillä), saa kaikki heikohkot salasanat ajettua yhdellä bruteforcauksella. Jos jokaisella on riittävä käyttäjäkohtainen suola, niin jokaisen käyttäjän salasanan joutuu bruteforcaamaan erikseen ja silti tarvii lisäksi tietää se mahdollinen järjestelmänlaajuinen suola.
Metabolix kirjoitti:
Jos SQL-injektion mahdollisuutta ei ole, globaalista suolasta ei ole mitään lisähyötyä suhteessa käyttäjäkohtaiseen suolaan.
Mitäs hyötyä niistä suoloista muuten on, jos SQL-injektiota tai muuta keinoa päästä kannan tietoihin ei ole? Siis meinaan jos krakkeri ei saa käsiinsä tiivistettä niin.. Oikeastaan siinä tapauksessa koko tiivistäminenkin on turhaa.
MD5 (tai SHA1, tai vaikka SHA2-512) on oikeasti suolattunakin nykyaikana melko turha sellaisilla salasanoilla, joita normaalit ihmiset käyttää, jos suola(t) saadaan myös selville. Kuten jo aikaisemmin sanoin, niin bcrypt (tai muu vastaava)
tok kirjoitti:
MD5(parametri1=arvo1;parametri2=arvo2;...
;parametriN=arvoN;MD5(salasana)).
Periaatteessahan tuossa ei ulkopuolisen tarvitse nähdä kuin yksi viesti, jonka jälkeen salasanan pystyy murtamaan omalla koneella. Kaikki parametrithan ovat selväkielisenä viestissä, joten ainoa tuntematon on salasana, jota muuttamalla voi koko viestin hashia verrata alkuperäiseen.
Salasanoja arvatessa täytyy kyllä laskea MD5 kahteen kertaan ja lisäksi nuo parametrit toimivat "luonnollisena" suolana. Toisaalta salasanaan voi kuitenkin käyttää valmiita tauluja, mikä käytännössä poistaa kaksinkertaisen laskemisen edun jos salasana löytyy tauluista. Joka tapauksessa murtuminen riippuu kuitenkin pelkästään salasanan vahvuudesta. Jos salasana on heikko, tuo murtuu aika nopeasti, jonka jälkeen ulkopuolinen voi esittää olevansa kyseinen henkilö kunnes salasana vaihdetaan.
Dimple kirjoitti:
Jos salasana on heikko, tuo murtuu aika nopeasti
Niin, se hyvä puoli noissa pankkien maksupainike- ja tupas-virityksissä sentään on, että kädettömät osapuolet ei saa itse valita sitä jaettua salaisuutta, vaan pankki generoi kohtuullisen vaikean sellaisen.
Grez kirjoitti:
Mitäs hyötyä niistä suoloista muuten on, jos SQL-injektiota tai muuta keinoa päästä kannan tietoihin ei ole?
Niin, optimitilanteessa olisi turvallista tallentaa kantaan vaikka plaintext. ;)
Onhan noita mahdollisuuksia aina muunlaisista bugeista yksinkertaiseen huolimattomuuteen. Eräät vainoharhaiset ovat tälläkin foorumilla meuhkanneet jopa epärehellisestä webhostingista ja kovalevyjen fyysisestä varastamisesta. Oma mielipiteeni kyllä on, että kaikenlainen salasanahifistely menee lähes aina hukkaan, jos softa on edes suunnilleen kunnossa.
Dimple kirjoitti:
tok kirjoitti:
MD5(parametri1=arvo1;parametri2=arvo2;...
;parametriN=arvoN;MD5(salasana)). Periaatteessahan tuossa ei ulkopuolisen tarvitse nähdä kuin yksi viesti, jonka jälkeen salasanan pystyy murtamaan omalla koneella.
MD5(salasana) on kuitenkin 128-bittinen, joten sen selvittämisessä ulommasta hashista kestää aika kauan (ainakin, jos on suolattu oikein).
Itse salasanaa ei tosiaan tarvitse tässä murtaakaan, koska pelkällä hashilla pystyy jo generoimaan uusia viestejä. Eli heti löytyi omasta viritelmästä aukko (tosin helposti hätäkorjattava, mutta se jääköön kotitehtäväksi), joten eiköhän kannata suosiolla vaihtaa johonkin "oikeaan" salaukseen tai tunnistukseen.
Metabolix kirjoitti:
Itse salasanaa ei tosiaan tarvitse tässä murtaakaan, koska pelkällä hashilla pystyy jo generoimaan uusia viestejä.
Kuten Dimple sanoikin, niin todennäköisesti toimivampi ratkaisu on murtaa se sisempi salasana. Nimittäin 128 bittinen salasana on jo aika paha bruteforcettaa, kun taas sisempi salasana ei ole suurella todennäköisyydellä läheskään niin pitkä.
Metabolix kirjoitti:
Oma mielipiteeni kyllä on, että kaikenlainen salasanahifistely menee lähes aina hukkaan, jos softa on edes suunnilleen kunnossa.
No joo, aina ei ole edes omasta softasta kiinni kun käyttiksestä, frameworkista tai tietokannasta löytyy joku nollapäivähaavoittuvuus jota joku ehtii käyttää. Riippuu nyt mitä kukakin pitää hifistelynä. Omasta mielestä esim. bcrypt ei ole hifistelyä. Tai jos on niin ennemmin sit hifistelen kuin rakennan omat linnunpönttökaiuttimet ilman minkäänlaista käsitystä mitoituksesta ja jakosuotimista.
Niin, no kun tässä on parikymmentä viestiä jo suolauksesta kirjoitettu, oletin, että voitaisiin katsoa MD5(salasana)-kohdan sisältävän myös kunnollisen suolan. Kun suola on yli 128-bittinen, sisemmän salasanan selvittämisestä tulee tiivisteen selvittämistä hankalampi tehtävä.
No missäs se suola sitten välitetään niin ettei se ulkopuolinen saa sitäkin selville? Käytännössä on sitten sama asia kuin hyvin pitkä salasana. Mun mielestä siinä luki hyvin selvästi MD5(salasana) eikä MD5(suola+salasana) ja en mieluusti lähtis liikaa olettamaan. :D
Suolauksesta pieni nopea tiivistys. Suolan tulee olla uniikki joka riville ja ennalta arvaamaton ja tarpeeksi pitkä (email ei siis kelpaa suolaksi). Ennalta arvaamaton ja tarpeeksi pitkä sen takia, että hyökkääjä ei hyödy vaikka hän etänä selvittää salasanan tiivisteen (käyttää "==" -vertailun tjms. aikavuotoa hyväkseen) ja sitten pääsee itse optimaalisessa ympäristössään hyökkäämään tätä tiivistettä vastaan. Tietysti tuo aikavuoto voidaan eliminoida, mutta ongelma pitäisi aina ratkaista "matalimmalla tasolla".
"globaalista suolasta" ja rivikohtaisesta suolasta vielä lyhyt recap. Yllä tämä tuli jo ilmi, mutta korostan vielä että ne eivät ole ollenkaan sama asia ja niillä ei oikeastaan ole toistensa kanssa mitään tekemistä. Se että käytät toista ei missään tapauksessa ole syy olla käyttämättä toista. Tuo termi "globaali suola" on oikeastaan todella huono, sillä se sekoittuu juuri tämän rivikohtaisen suolan kanssa. Alkujaan käytettiin "local parameterization" termiä, mikä siis on kuin esim. tuo konffitiedostossa oleva yhteinen jaettu salaisuus. Mutta sekin vielä, kuten sanottua, että onko tuollaisesta todellisuudessa hyötyä, on kokonaan toinen juttu. Siis silloin kun tämä "parametri" on tallennettu samalle palvelimelle itse ohjelmakoodin kanssa (tai ohjelmakoodipalvelimelta on pääsy tähän parametriin). Ennemmin siis hoitaa salasanan käsittelyn (esim. bcrypt) jne muut vaatimukset (password policy) kuntoon ja be happy.
tok kirjoitti:
MD5(parametri1=arvo1;parametri2=arvo2;...
;parametriN=arvoN;MD5(salasana))
Näettekö tässä protokollassa jotain turvallisuusaukkoja
Lyhyt vastaus:
Kyllä.
Pidempi vastaus:
Mahdollisesti tuo toimii, mutta luulen että tähän on päästy vahingossa ("toimii" sen takia, että olet laittanut salasanan tiivisteen hashattavan komentorimpsun loppuun). Mutta joka tapauksessa tuossa on iso pelko että uikkarit tippuvat jalasta (ainakin siihen asti kunnes SHA-3 tiivistefunktio julkaistaan). Toinen tärkeä nyanssi tässä on että ole aivan varma siitä että tuo komentorimpsu koostetaan niin että se saa saman merkityksen kuin mitä on tarkoitettu lähetettäessä. Horton Principle: You should authenticate the meaning, not the message.
En usko että julkisen avaimen salaus on tässä se way to go (siis muuten kuin että tuota protokollaa käytetään salatun yhteyden kautta), vaan helpoiten homman muutat kuntoon käyttämällä esim. HMAC:ia. HMAC-avain on joku satunnaisesti generoitu, esim. 128 tai 256-bittinen luku (mikä on siis molemmilla osapuolilla tiedossa, tai ainakin niin että molemmat osapuolet voivat muodostaa lopullisen salasanan jotenkin). Toinen tärkeä juttu on käyttää salattua yhteyttä.
P.S. Luulen tunnistavani itseni epärehellisen webhostingin maininnasta :D Tarkennan vielä, että ajoin takaa sitä että ei kannata luottaa mihinkään ns. turhaan. Mitä vähemmän systeemisi turvallisuus riippuu erilaisista luottamuksista eri suuntiin, niin sitä parempi (suurimmassa osassa tapauksia tietysti täytyy voida luottaa siihen webhostiin). En kutsuisi tätä vainoharhaksi, vaan "professional paranoiaksi" ;)
Grez kirjoitti:
Yksi haitta toki tietysti on se, että jos jokin saa selville käyttäjän MD5 -tiivisteen esim. tietoturva-aukon avulla, niin hän pystyy esiintymään ko. käyttäjänä tietämättä tämän salasanaa.
Hyvä pointti. Tämä on aivan totta, pelkän MD5-tiivisteen avulla voi esiintyä toisena käyttäjänä.
Grez kirjoitti:
Itse näkisin tuohon tarkoitukseen paljon parempana julkisen avaimen kryptografian ja miksei vaikka jo valmiiksi tarjolla olevia käyttäjä- ja palvelinsertifikaattimenetelmiä. Aina ei tarvitse keksiä pyörää uudestaan.
En ole kovin perehtynyt julkisen avaimen tekniikoihin, mutta yksinkertaisimmillaan se kai menisi jotenkin näin:
1) asiakas kryptaa sanasanansa käyttäen palvelimen julkista avainta
2) asiakas liittää käyttäjätunnuksensa ja kryptatun salasanan viestiin
3) palvelin avaa salasanan omalla salaisella avaimellaan
4) palvelin autentikoi asiakkaan avatulla salasanalla
Mitäs jos joku kaappaa viestin, eikö sanakirjahyökkäys ole tässä yhtä lailla mahdollinen? Palvelimen julkinen avain on saatavilla, otetaan se, kryptataan salasanaehdokkaita ja verrataan viestistä saatuun kryptattuun salasanaan.
Vai onko mahdollista kryptata viesti sekä vastaanottajan julkisella avaimella että omalla salaisella avaimella (ja avata vastaanottajan salaisella + lähettäjän julkisella)? Tällöin sanakirjahyökkäys ei toimisi, koska lähettäjän salainen avain ei ole tiedossa.
timoh kirjoitti:
En usko että julkisen avaimen salaus on tässä se way to go (siis muuten kuin että tuota protokollaa käytetään salatun yhteyden kautta), vaan helpoiten homman muutat kuntoon käyttämällä esim. HMAC:ia. HMAC-avain on joku satunnaisesti generoitu, esim. 128 tai 256-bittinen luku (mikä on siis molemmilla osapuolilla tiedossa, tai ainakin niin että molemmat osapuolet voivat muodostaa lopullisen salasanan jotenkin). Toinen tärkeä juttu on käyttää salattua yhteyttä.
En varsinaisesti tarkoittanut salaamista, vaan allekirjoittamista salaisella avaimella. Ehdottamassasi HMAC-ratkaisussa sen jaetun salaisuuden saaminen palvelimelta edelleen mahdollistaa esiintymisen käyttäjänä palvelimelle. Jos käyttäjä käyttäisi salaista avainta ja palvelimella olisi tiedossa vain käyttäjän julkinen avain, ei tuon tiedon ulos saaminen palvelimelta mahdollistaisi käyttäjänä esiintymistä.
timoh kirjoitti:
Mitä vähemmän systeemisi turvallisuus riippuu erilaisista luottamuksista eri suuntiin, niin sitä parempi
Tässä käytännössä perustelitkin, miksi ehdotuksesi oli epäoptimaalinen :D
tok kirjoitti:
Mitäs jos joku kaappaa viestin, eikö sanakirjahyökkäys ole tässä yhtä lailla mahdollinen?
Koko autentikaation voisi tehdä ilman salasanaa perustuen käyttäjän julkiseen avaimeen, jolloin sanakirjahyökkäys on pois kuvioista. Toki asymmetrisessa kryptografiassakin on omat ongelmansa, mutta niihin on myös aika hyvät ratkaisut. En lähtisi keksimään pyörää uudelleen.
Yleisesti ottaen jos turvaratkaisu perustuu käyttäjän salasanaan (ja sen päälle kertyvään tauhkaan) niin vaikka ketju muuten olisi miten vahva, niin huono salasana on aina heikko lenkki.
timoh kirjoitti:
Pidempi vastaus:
Mahdollisesti tuo toimii, mutta luulen että tähän on päästy vahingossa ("toimii" sen takia, että olet laittanut salasanan tiivisteen hashattavan komentorimpsun loppuun). Mutta joka tapauksessa tuossa on iso pelko että uikkarit tippuvat jalasta (ainakin siihen asti kunnes SHA-3 tiivistefunktio julkaistaan). Toinen tärkeä nyanssi tässä on että ole aivan varma siitä että tuo komentorimpsu koostetaan niin että se saa saman merkityksen kuin mitä on tarkoitettu lähetettäessä. Horton Principle: You should authenticate the meaning, not the message.
Hyvää pohdiskelua, kiitos paljon! Voisitko vielä vähän vääntää auki paria kohtaa yllä olevasta. Mitä tarkoitat että "tähän on päästy vahingossa"? Ja miksi rimpsu ei saisi samaa merkitystä vastaanottaessa?
Tuohon HMACiin pitää perehtyä tarkemmin. Kiitos vinkistä.
Grez kirjoitti:
Koko autentikaation voisi tehdä ilman salasanaa perustuen käyttäjän julkiseen avaimeen, jolloin sanakirjahyökkäys on pois kuvioista. Toki asymmetrisessa kryptografiassakin on omat ongelmansa, mutta niihin on myös aika hyvät ratkaisut. En lähtisi keksimään pyörää uudelleen.
Koska olen onneton newbie kryptografian suhteen, yritän vääntää rautalangasta:
1) asiakas toimittaa julkisen avaimensa palvelimelle
2) asiakas signeeraa viestinsä salaisella avaimellaan
3) palvelin tarkistaa viestin signeerauksen asiakkaan julkisella avaimella
4) jos signeeraus on ok, niin asiakas on se kuka väittää olevansa
Näinkö?
Joo, tuossahan tietysti voi olla ongelmana kohta 1. Mutta jos vaikka asiakas livenä tapaa palvelimen ylläpitäjän, näyttää henkkarit ja antaa palvelimen pitäjälle julkisen avaimensa, niin palvelimen pitäjä voi olla melko varma asiasta ;D
Tilanne ei tietenkään olisi salasanan kohdalla yhtään helpompi.
Ja tietty kohtaan 4 voisi tarkentaa, että palvelin tietää vastapuolella olevan asiakkaan salaisen avaimen :D
Grez kirjoitti:
Joo, tuossahan tietysti voi olla ongelmana kohta 1. Mutta jos vaikka asiakas livenä tapaa palvelimen ylläpitäjän, näyttää henkkarit ja antaa palvelimen pitäjälle julkisen avaimensa, niin palvelimen pitäjä voi olla melko varma asiasta ;D
Tässä tapauksessa ei tarvitse olla ihan noin tiukka kuri. Ei tämä sentään mikään pankkijärjestelmä ole :-)
Grez kirjoitti:
Ja tietty kohtaan 4 voisi tarkentaa, että palvelin tietää vastapuolella olevan asiakkaan salaisen avaimen :D
??? Mitä tällä tarkoitit?
Grez kirjoitti:
En varsinaisesti tarkoittanut salaamista, vaan allekirjoittamista salaisella avaimella. Ehdottamassasi HMAC-ratkaisussa sen jaetun salaisuuden saaminen palvelimelta edelleen mahdollistaa esiintymisen käyttäjänä palvelimelle. Jos käyttäjä käyttäisi salaista avainta ja palvelimella olisi tiedossa vain käyttäjän julkinen avain, ei tuon tiedon ulos saaminen palvelimelta mahdollistaisi käyttäjänä esiintymistä.
timoh kirjoitti:
Mitä vähemmän systeemisi turvallisuus riippuu erilaisista luottamuksista eri suuntiin, niin sitä parempi
Tässä käytännössä perustelitkin, miksi ehdotuksesi oli epäoptimaalinen :D
Totta kyllä :D Mutta en silti näkisi MAC:in käyttöä varsin huonoksi ratkaisuksi tällaisessa tilanteessa. Se on paljon helpompi ja tehokkaampi toteuttaa kuin digital signaturet (tokin tapauksessa käytännössä taitaa riittää että korvaa koodissa luokkaa yhden rivin). Mutta tosiaan puhtaasti teknisiltä ominaisuuksiltaan digital signaturet ovat parempia, sitä ei käy kiistäminen.
tok kirjoitti:
Hyvää pohdiskelua, kiitos paljon! Voisitko vielä vähän vääntää auki paria kohtaa yllä olevasta. Mitä tarkoitat että "tähän on päästy vahingossa"? Ja miksi rimpsu ei saisi samaa merkitystä vastaanottaessa?
Nykyisillä tiivistefunktioilla on ominaisuus (ongelma), mistä johtuu että suht pienellä vaivalla hyökkääjä voi muodostaa uuden oman viestinsä (missä on hyökkääjän kaappaamaan alkuperäiseen oikeelliseen viestiin lisätty hyökkääjän omaa dataa) ja tälle käyvän "signaturen" tietämättä salaista avainta.
http://en.wikipedia.org/wiki/
Meinasin että pidä huoli että viesti parsiutuu varmasti siksi mitä oli tarkoitettu, tyyliin että ei ilmene mitään epäyhteneväisyyksiä lähettäjän ja vastaanottajan puolella. Vaikka jos protokollasi päivittyy ja tämä vaikuttaa datan parsimiseen, niin kuinka käy datalle mikä saapuu vanhalla versiolla. Käytännössä tuo tarkoittaa sitä että mahdollisesti lisäät tuon varmenteen alle vaikka protokollan versionumeron tjms, minkä avulla sitten vastaanottajan puolella voi olla varma että kuinka viesti tulee parsia kasaan. Myös timestamppeja on tuollaisissa hyvä käyttää (voit olla varma että liian vanhoja viestejä ei hyväksytä jne). Käytännössä liitä varmenteen alle kaikki data mikä millään tapaa liittyy tuohon operaatioon (versionumerot, aikaleimat jne).
Miten olis systeemi jossa palvelimelle on tallennettu 1 hash salasanasta. Salasanaa vaihdettaessa tai käyttäjää luodessa se lasketaan tietyllä käyttäjäkohtaisella kaavalla, joka annetaan myös sisäänkirjautumissivulle suoraan HTML koodiin upotettuna (javascript?). Olennaista on että laskeminen kestäisi kauan, sanotaan vaikka 2 sekuntia yksi-ytimisellä 2.4GHz prosessorilla.
Kaava voi olla esim:
n = user_n // Tietokantaan käyttäjälle tallennettu luku, esim 100000 (siis aina joku suuri luku vaikka väliltä 100000..150000, mitoitettu laskenta-aikaan) (TAI ehkä n:n voisi yksinkertaisesti laskea käyttätunnuksesta) hash = salasana_input for i=1..n hash = MD5(string(n)+hash+hash)
Eli tässä tapauksessa pitäisi palvelimelta saada user_n ennen kuin salasanan hashia voi lähettää tunnistautumiseen. Palvelin itse ei tee mitään muuta kuin vertaa sitä tallennettuun hashiin. Näin säästyy myös resursseja kun sen ei tarvitse tehdä suuria operaatioita kirjautumisessa. Ja mikään listapohjainen hyökkäys ei tehoaisi.
Muokattu taas. Jos itse n sisältyy hashiin ja n on laskettu käyttäjänimestä, niin käyttäjänimen vaihtamisen yhteydessä pitää pakottaa myös salasanan vaihto. Mutta jos n ei sisälly, niin hyökkääjä voi tehdä listan vaikka esimerkkitapauksessa valmiiksi 100000 asti jolla säästää laskenta-aikaa. Mutta vaikka hakkerin kone-verkon teholla tuota laskenta-aikaa voisi supistaa vaikka 0.01 sekuntiin niin suurilla salasanamäärillä aikaa kuluisi silti. No kuitenkin 8 miljoonaa päivässä ;p
User137 kirjoitti:
Miten olis systeemi jossa...
Ei kannata lähteä tuollaiselta pohjalta. Mitä ongelmakohtaa ylipäätään lähdit ratkaisemaan tällä systeemillä?
Käytettävyysongelmien lisäksi tuo on tuollaisenaan heikko tietoturvan kannalta. Lyhyesti sanottuna tuo ei ratkaise niitä ongelmia mitä salattu yhteys (HTTPS) ratkaisee, eikä tuo käy challenge-response systeeminäkään. Sekin vielä että joudut hoitamaan crypto-operatioita javascriptillä on tuhoon tuomittu jo lähtökohtaisesti.
Tiivisteen laskentaan käytetyn ajan lisäys mahdottoman suureksi ei ole oikea paikka ratkaista ongelmaa. Sen sijaan anna serverin hoitaa tiivisteen laskenta, sopivalla cost-parametrillä. Lisää turvaa tiivisteille saat vaatimalla salasanoilta tarpeeksi pituutta tjms. Kaiken lisäksi tämä on future proof, koska cost-parametriä voidaan suurentaa tarvittaessa.
Kannattaa pysyä suosituksissa ja hoitaa homma niin kuin on ajan saatossa todettu olevan paras.
http://www.openwall.com/articles/PHP-Users-Passwords:
- "My web application must be fast. I can't afford to use a slow hash function!"
- Actually, you can. No one said it should be taking an entire second to compute a password hash. Is 10 milliseconds fast enough for you? Perhaps it is, but if not you can make it 1 ms or less (which is likely way below other per-request "overhead" that your application incurs anyway) and still benefit from password stretching a lot. Please note that without any stretching a cryptographic primitive could be taking as little as some microseconds or even nanoseconds to compute (at least during an offline attack, which would use an optimal implementation) . If you go from one microsecond to one millisecond, which is clearly affordable, you make offline attacks (against stolen or leaked hashes) run 1000 times slower, or you effectively stretch your users' passwords or passphrases by about 10 bits of entropy each. That's significant - it is roughly equivalent to each passphrase containing one additional word, without actually adding that extra word and having the users memorize it. Besides, the password hash is typically only computed when a user logs in (or when a new user is registered or a password is changed), which occurs relatively infrequently (compared to the frequency of other requests). Subsequent requests by the logged in user will use a session ID instead.
Lähinnä toiseen viestiin vastasin
Grez kirjoitti:
Suolan idea on estää rainbow-taulujen käyttö, ei tehdä salasanakohtaista sanakirjahyökkäystä olennaisesti vaikeammaksi.
Salattu yhteys on tästä asiasta erillään, oletan että sen hoitaa vaikka HTTPS tvs. Kyllä sitäkin tapahtuu että esim. jonkun massiivisen moninpelin palvelin ruuhkautuu sillä hetkellä kun se avataan uudestaan, syystä tai toisesta.
lainaus:
Sekin vielä että joudut hoitamaan crypto-operatioita javascriptillä on tuhoon tuomittu jo lähtökohtaisesti.
Voitko tarkentaa tuota? Oletin siis pääasiassa että palvelimelta ei kysytä sitä n-lukuarvoa vaan se lasketaan käyttäjänimestä. Tiedän toki että hakkeri osaa itse muodostaa hashin kokeiltavasta salasanasta, mutta siitä vaan. Ei siitä ole mitään apua kun bruteforcettamisessa, tulisi kestämään liian kauan. Sanakirjahyökkäykset eivät edes ole mahdollisia.
User137 kirjoitti:
lainaus:
Sekin vielä että joudut hoitamaan crypto-operatioita javascriptillä on tuhoon tuomittu jo lähtökohtaisesti.
Voitko tarkentaa tuota? Oletin siis pääasiassa että palvelimelta ei kysytä sitä n-lukuarvoa vaan se lasketaan käyttäjänimestä. Tiedän toki että hakkeri osaa itse muodostaa hashin kokeiltavasta salasanasta, mutta siitä vaan. Ei siitä ole mitään apua kun bruteforcettamisessa, tulisi kestämään liian kauan. Sanakirjahyökkäykset eivät edes ole mahdollisia.
Se että suoritat selaimessa javascriptillä crypto-operaatioita, ei ole ideaalista sen takia, että tämä "ympäristö" on hyökkäyksille erityisen altis (mitä cryptosysteemiltä ei odoteta). Tässä kun ilmeisesti yrität torjua sitä ongelmaa, että salasanat kaapataan plaintextinä lennosta (koska ei ole suojattua yhteyttä), niin se ongelma on paljon alemmalla tasolla juuri sen takia koska ei ole sitä suojattua yhteyttä.
Nyt jos itse javascriptillä muokkaat salasanaa ennen kuin lähetät sen verkon yli, niin et voi mitenkään olla varma että suorittaako selain juuri sitä sinun javascript-koodiasi, vai onko mukana mahdollisesti hyökkääjän koodia (mikä vie salasanan jo siinä kohtaa kun se on ihan plainteksiä). Javascript-koodisi ei pysty itse millään suorittamaan mitään "sanity checkejä" että "onko nyt kaikki kunnossa". Käytännössä tuo vaatisi jotain tyyliin jonkinlainen selaimen lisäosa (mikä siis hoitaisi tuon salasanan käsittelyn), että tuollaista edes kannattaisi harkita. Käytännössä jos et voi luottaa siihen että salasanat menevät turvallisesti käyttäjältä serverille, et voi tuota mitenkään tyhjästä taikoakaan että javascriptin avulla se onnistuisi oleellisesti turvallisemmin. Se javascript kulkee täysin samaa kanavaa pitkin kuin salasanatkin.
Sitten myös protokollassasi on se ongema, että palvelin joutuu tallentamaan tiedon mikä vastaa salasanaa (eli jos se varastetaan, sillä voidaan kirjautua systeemiisi). Huomaa että perinteisissä systeemeissä tätä ongelmaa ei ole, siis silloin kun salasanat tallennetaan esim. bcryptillä tjms. ylipäätään tiivistettynä.
Tuollainen chalenge-response protokolla on mahdollista toteuttaa ilman että plaintext salasanaa (tai salasanaa vastaavaa tietoa) joudutaan palvelimelle tallentamaan, mutta tämä juuri vaatii tätä asiakkaan päässä suoritettavaa operointia (mikä ei siis selain+javascript yhdistelmällä toimi). Joten webbiimaailmassa on parempi pysytellä siinä että käsittelee salasanat oikein ja hoitaa muut tarvittavat tietoturvakuviot siihen alle (suojattu yhteys).
User137 kirjoitti:
Grez kirjoitti:
Suolan idea on estää rainbow-taulujen käyttö, ei tehdä salasanakohtaista sanakirjahyökkäystä olennaisesti vaikeammaksi.
Salattu yhteys on tästä asiasta erillään, oletan että sen hoitaa vaikka HTTPS tvs. Kyllä sitäkin tapahtuu että esim. jonkun massiivisen moninpelin palvelin ruuhkautuu sillä hetkellä kun se avataan uudestaan, syystä tai toisesta.
En ihan nyt osaa yhdistää miten minulta lainaamasi pätkä liittyy tuohon mitä kirjoitit.
Yhdistin tuosta lainauksesta asiaan vain termit "rainbow-taulut", "sanakirjahyökkäys". Eli melko sama keneltä lainaan, mutta mainitsit ne ketjussa ensimmäisenä. No, jos siitä vielä lainaan "bcrypt":n niin serverikö sen laskisi?
timoh kirjoitti:
Tässä kun ilmeisesti yrität torjua sitä ongelmaa, että salasanat kaapataan plaintextinä lennosta (koska ei ole suojattua yhteyttä), niin se ongelma on paljon alemmalla tasolla juuri sen takia koska ei ole sitä suojattua yhteyttä.
En edes ajatellut moista. Mielessä oli lähinnä ongelma että hakkeri yrittää arvata/bruteforcettaa käyttäjän salasanaa omalta clientiltaan, kenties käyttäen apunaan "sanakirjahyökkäystä".
Eikai nyt HTTPS-suojauksen käyttö estä java-scriptin suorittamista kirjautumisen yhteydessä? Se on vain yksi palikka siinä välissä kun käyttäjän antama input lähtee palvelimelle napin painalluksella. Jos sivu on hakkeroitu niin yhtä lailla hakkeri voi vaikka muuttaa napin toiminnan lähettämään käyttäjätunnuksen ja salasanan plaintextinä tilapäiseen sähköpostiinsa. Tuossa nyt on kyse jostain ihan muusta perustavanlaatuisesta tietoturvasta.
Palvelimella on siis tallennettuna vain ja ainoastaan hyvin pitkä hash merkkijono salasanalle joka on vain laskettu etukäteen. Voi sille jonkun kevyen dekryptauksen suorittaa vielä vertailuvaiheessa, mutta pääpointti on että palvelimen toiminta nopeutuu. Ja jos hakkeri saisikin käsiinsä salasanan hashin, siitä ei saisi itse salasanaa ulos missään inhimillisessä ajassa.
Ahaa nyt ilmeisesti ymmärsin mitä ajat takaa. Kieltämättä "sanakirjahyökkäys" ihan loginia kokeilemalla on ehkä hieman erikoinen taktiikka, ainakin siihen verrattuna mitä sanakirjahyökkäyksellä yleisesti tarkoitetaan. Mutta kyllähän se tili noinkin voi murtua. Siinä mielessä ihan validi pointti.
Mutta, tuon ongelman ratkaiset (tai no, pienennät vaikutusta) loginkäsittelyssä, esim. pidennät aikaa palauttaa vastaus jos näyttää että hyökkäys on käynnissä tiettyä tiliä vastaan (huomaa että oikeallakin salasanalla tulisi vastauksen palauttamisen tällaisessa tapauksessa kestää yhtä lailla kauemmin). Voit myös käyttää jotain captchan tyylistä kirjautuessa (tämäkin siis vain jos näyttää että tiliä vastaan on hyökkäys päällä). Kunhan et vaan mene kokonaan sulkemaan tiliä. Jos käytät tuota "palautuksen pitkittämistä", varmista että et altista systeemiäsi palvelunestohyökkäykselle.
Voit tulkita että tiliä vastaan hyökätään, jos esim. viimeisen x ajan sisällä on y määrä epäonnistuneita kirjautumisyrityksiä tietylle tilille. Oikeellisen kirjautumisen yhteydessä tuo counter nollantuu (mikä tietysti antaa hyökkääjälle hieman helpotusta aina sen jälkeen kun oikea käyttäjä kirjautuu tililleen).
Metabolix kirjoitti:
Itse salasanaa ei tosiaan tarvitse tässä murtaakaan, koska pelkällä hashilla pystyy jo generoimaan uusia viestejä. Eli heti löytyi omasta viritelmästä aukko (tosin helposti hätäkorjattava, mutta se jääköön kotitehtäväksi), joten eiköhän kannata suosiolla vaihtaa johonkin "oikeaan" salaukseen tai tunnistukseen.
No älä pidä meitä enää jännityksessä vaan kerro malliratkaisu kotitehtävään :-)
Oma viritys vaihtuu kyllä oikeaan salaukseen, mutta ihan mielenkiinnosta ja oppimisen kannalta: miten olisit hätäkorjannut sen?
Aihe on jo aika vanha, joten et voi enää vastata siihen.