Minäpäs lainaan hieman ketjua tälläiselle pienelle kysymyksellä joka on askarruttanut mieltäni.
Kun aina aika ajoin nousee esille ihan normi mediassakin ihmisten (edelleen) huonot ja yksinkertaiset salasanat ja niissä aina kehoitetaan että pitäisi olla näin karrikoidusti vähintään 20 merkkiä ja kaikki mahdolliset koukerot ja muut erikoismerkit mukana että sitä olisi millään brute force tai sanakirja hyökkäyksellä mahdollisimman hankala saada selville.
Miksei yksinkertaisesti ole niin että kirjautumisyrityksen jälkeen täytyy kulua x määrä aikaa ennen kuin voi yrittää seuraavan kerran? Jos esim kirjautusmisyritysten väli olisi pakotettu vaikka kahteen sekunttiin niin eikö tuo aika hyvin kampittaisi näitä tälläisiä hyökkäyksiä? Itsehän en siis ohjelmoinnista enkä näistä tiedä mutta on vain monesti mietityttänyt kun näistä on lukenut. Jos tuo aika pitenisi aina jokaisesta epäonnistuneesta kirjautumisyrityksestä niin se olisi vielä entistä parempi.
Osassa ohjelmia ja palveluitahan näin on mutta olen saanut ainakin näiden lukemieni juttujen perusteella kuvan ettei kuitenkaan mikään kaikkien käyttämä tapa kerta aina tuodaan esille missä ajassa minkäkin pituinen salasana saadaan arvattua.
Salasanoja ei murreta tekemällä kirjautumisyrityksiä palveluun vaan lähes aina krakkerilla on lista käyttäjätunnuksista ja salasanatiivisteistä. Yksinkertaistettuna, krakkeri laskee tiivisteitä eri syötteillä ja vertaa laskettua tiivistettä hänellä olevaan listaan tiivisteistä. Jos laskettu tiiviste löytyy listasta, hän tietää kyseisen käyttäjän salasanan.
Tätä hommaa tosiaan vaikeuttaa huomattavasti jos listassa olevat tiivisteet ovat laskettu jollain moderneista algoritmeistä, jotka ovat tarpeeksi työläitä laskea.
Pikaisesti kurkattuna yhdellä Nvidia GTX 1080 kortilla pystyy laskemaan 25 miljardia MD5-tiivistettä sekunnissa tai 13000 bcrypt-tiivistettä sekunnissa. Lähde: 8x Nvidia GTX 1080 Hashcat Benchmarks
Ääni Argon2:lle, sillä saa hyvin säädettyä helpoilla parametreillä rinnakkaisuuden, muistinkäytön ja iteraatioiden lukumäärän avulla omaan käyttötarkoitukseensa sopivan.
Minäpäs lainaan hieman ketjua tälläiselle pienelle kysymyksellä joka on askarruttanut mieltäni.
Kun aina aika ajoin nousee esille ihan normi mediassakin ihmisten (edelleen) huonot ja yksinkertaiset salasanat ja niissä aina kehoitetaan että pitäisi olla näin karrikoidusti vähintään 20 merkkiä ja kaikki mahdolliset koukerot ja muut erikoismerkit mukana että sitä olisi millään brute force tai sanakirja hyökkäyksellä mahdollisimman hankala saada selville.
Miksei yksinkertaisesti ole niin että kirjautumisyrityksen jälkeen täytyy kulua x määrä aikaa ennen kuin voi yrittää seuraavan kerran? Jos esim kirjautusmisyritysten väli olisi pakotettu vaikka kahteen sekunttiin niin eikö tuo aika hyvin kampittaisi näitä tälläisiä hyökkäyksiä? Itsehän en siis ohjelmoinnista enkä näistä tiedä mutta on vain monesti mietityttänyt kun näistä on lukenut. Jos tuo aika pitenisi aina jokaisesta epäonnistuneesta kirjautumisyrityksestä niin se olisi vielä entistä parempi.
Osassa ohjelmia ja palveluitahan näin on mutta olen saanut ainakin näiden lukemieni juttujen perusteella kuvan ettei kuitenkaan mikään kaikkien käyttämä tapa kerta aina tuodaan esille missä ajassa minkäkin pituinen salasana saadaan arvattua.
Tuo ajan piteminen oli kyllä hyvä idea jos väärinkirjoitetun jälkeen aina aika pitenisi muutaman sekunnin kerrallaan(ja jos vaikka 10x laitat väärin ip lukkoon 5tunniksi tms). Kerran vuodessa vieläkun sais käyttäjät pakotettua vaihtamaan salasanan (vähä hankala toteuttaa) , ja jos pakotus tulee useimmin se käy liian paljon hermoille. Yleensäkkin tiliä luodessa johonkin paikkaan olis hyvä että salasanaksi kelpaisi vain yli 15 merkkiset jossa ois noita erikoismerkkejä isoja sekä pieniä + numeroita. Tuommoisia yhdistelmä salasanoja kuin joutuis pakosta käyttämään joka paikassa niin 20 vuoden päästä se ei tunnu enää niin pahalta vaan rutiininomaiselta sitten pikemminkin eikä kukaan edes muista että johonkin kelpas 5 merkkiset salasanat joka oli sitä qwerty tyyliä.
Mutta kyllä sitä itsekkin syyllistyy siihen että "hällä väliä" paikoissa on kehnot salasanat , mutta mitä tärkeimpiin paikkoihin mennään niin sitten vasta salasanatkin vahvistuu...Ja aivan liian harvoin tulee vaihdettua.
Mutta tämäkin on vähä semmoinen asia joka täytyisi opettaa 1-luokkalaisille jo hyvissä ajoin, niin ehkä joskus tilanne saattais muuttua. Kuten esim laitteiden päivitysten kohdalla. Ei nuoriso laitteitaan osaa päivittää tai käyttää riittävän hyviä salasanoja..Eikä se tilanne muutu koskaan jos asia ei saa enempää painotusta missään vaiheessa...
Salasanoja ei murreta tekemällä kirjautumisyrityksiä palveluun vaan lähes aina krakkerilla on lista käyttäjätunnuksista ja salasanatiivisteistä. Yksinkertaistettuna, krakkeri laskee tiivisteitä eri syötteillä ja vertaa laskettua tiivistettä hänellä olevaan listaan tiivisteistä. Jos laskettu tiiviste löytyy listasta, hän tietää kyseisen käyttäjän salasanan.
Tätä hommaa tosiaan vaikeuttaa huomattavasti jos listassa olevat tiivisteet ovat laskettu jollain moderneista algoritmeistä, jotka ovat tarpeeksi työläitä laskea.
Pikaisesti kurkattuna yhdellä Nvidia GTX 1080 kortilla pystyy laskemaan 25 miljardia MD5-tiivistettä sekunnissa tai 13000 bcrypt-tiivistettä sekunnissa. Lähde: 8x Nvidia GTX 1080 Hashcat Benchmarks
On, koska ensin käydään sanalistat läpi ja niiden perusteella johdetaan erilaisia yhdistelmiä. Paras salasana on täysin satunnainen ja pitkä, hankalampi käyttää sanalistoja murtamiseen.
Peruna tai peruna123 taitaa olla 99,9 % varmuudella arvattavissa listojen avulla hyvinkin nopeaa kun taas tuo jälkimmäinen sanayhdistelmä taitaa viedä yli ihmisen eliniän ennenkuin se on brutella "arvattu". Tai vois sanoa että parempi todennäköisyys on voittaa lotossa miljoona kuin että tuon jälkimmäisen sanayhdistelmän joku arvaisi/murtaisi. Toinen on tietysti joku tietomurto jossa nuo uniikitkin salasanayhdistelmät pääsee vuotamaan ja vaikka ois kuinka pro salasana niin pakkohan se on vaihtaa silti jonkun vahingon tapahtuessa. (luultavasti noita vuotaneita salasanoja kerätään listoiksi myös). Taitaa olla vain paras keino että käyttää tarpeeksi uniikkeja salasanoja joita vaihtelee riittävän usein. Valtaosaa kuitenkin suomen väestöstä ei varmaan vähempää vois kiinnostaa tämmöinen toiminta...(Eri salasanojen käyttö eri paikoissa ja niiden aktiivinen vaihtelu)
Ite pyrin vielä noudattamaan sitä että missään paikassa ei olisi samaa salasanaa, ja kuinkakohan moni suomalainen käyttää juuri peruna24 tyylistä salasanaa jokaisessa palvelussa Arvaan että aika moni..
Taidanki huomenna käyttää aikaa hieman paperille raapustamiseen ja suunnitella muutamat uniikit varalle jotka on sitten H-hetkellä helppo arpoa eri puolille nettiä...(En niin piittaa salasanojen tallennus ohjelmista)
yöllisiä mutuiluja..voi olla että nämä ajatukset ole sinnepäinkää muttamutta jatketaan !
Aikoinaan silloinen tyttis sai ohjeeksi käyttää jotain mieluista sanaa kaikkialla siten, että lisää vaikka väliin jotain vain kulloiseenkin sivustoon liittyvää. Eli sanotaan että hänen lempisanansasanansa oli, TykkäänJakaa69 ja sivusto vaikka Toosa. No, salasana muodostuisi sitten vaikka TykkäänToosaJakaa69. Jollain toisella sivulla sitten "Toosa" korvautuisi jollain muulla ko. sivustoon kuuluvalla. Tällähän pääsisi jo aika pitkälle, varsinkin kun oikeasti passu ei ollut noin selkeä.
Mutta ei. Tästäkään ei ollut apua, sillä myöhemmin auttaessa LastPassin käyttöön, tuli pistettyä merkille, että olipa sivusto mikä tahansa, oli kaikissa TykkäänToosaJakaa69 -salasana (eikä se ollut oikeasti näin pitkä passu edes)
Kerran vuodessa vieläkun sais käyttäjät pakotettua vaihtamaan salasanan (vähä hankala toteuttaa) , ja jos pakotus tulee useimmin se käy liian paljon hermoille.
Tätä minä en ole vielä ymmärtänyt, miksi hyvä ja ainoastaan yhdessä palvelussa käytössä oleva salasana pitäisi säännöllisesti vaihtaa? Jos se on vaarantunut, niin silloin säännöllinen vaihto on kuitenkin myöhässä.
Tätä minä en ole vielä ymmärtänyt, miksi hyvä ja ainoastaan yhdessä palvelussa käytössä oleva salasana pitäisi säännöllisesti vaihtaa? Jos se on vaarantunut, niin silloin säännöllinen vaihto on kuitenkin myöhässä.
Vaikka se vanha salasana olisi vaarantunut, niin voi olla ettei sitä ole vielä käytetty hyväksi. Tällöin salasanan vaihtaminen estää hyväksi käytön. Ei ne niitä kaikkia salasanoja ja tunnuksia ala kokeilemaan heti kun ovat jostain saaneet tunnukset tietoon. Voi mennä kuukausia ennen kuin joku ottaa tunnukset haltuun.
Hyviä pointteja. Mutta on myös otettava huomioon mistä palvelun salasanasta on kyse. Jos jonkun pilipalin salasana on päätynyt jonkun tietoon, niin kyse voi olla merkityksetön. Täytyy itse hieman miettiä mikä on tärkeää ja mikä ei. Silloin jaksaa panostaa laatuun. No, mielelläni käytän missä vain on käytössä, niin kaksivaiheista tunnistusta.
menee vähän offtopic mutta kun salasanoista puhutaan -> jos kerran käyttää mm. Lastpass tai Keepass palveluja, eikö fiksuinta ole tehdä kylmästi vaan se 512bit litania hash geniksellä ja varmuuskopioida kanta säännöllisesti.
pahinta mitä voi käydä on että unohdat salasanan ja joudut sen palauttamaan, etkä voi vahingossakaan esim. turvaamattomassa verkossa kirjautua vaikka sähköpostiin
Näinhän minä teenkin, siis käytän todella vahvoja salasanoja, joita en varsinaisesti itse tiedä alkuunkaan (harmi että vieläkin on paikkoja, joissa ei voi edes käyttää ns. vahvoja salasanoja). LastPass hoidellut hommat jo vuosia kuten pitääkin.
Mä ajattelen tätä asiaa enemmän, älkää loukkaantuko mutta "tavallisen" ihmisen kannalta jonka tietokoneen käyttö on lähinnnä verkkopankki asiointia tai verkkokauppa ostosten tekeminen tai uutisten lukeminen netissä. Se määrä mikä esim io-techillä lukee on toki iso joukko, mutta silti niin pieni osa suomen väestöstä. Ja tämä pieni joukko io-techillä osaa kyllä rekisteröityessään kertoa tarpeeksi vahvan salasanan, mutta miten tämä saatais ihan koululaisille jo opetettua , että se tilanne salasanojen kanssa olisi esim 10 vuoden päästä niin rutiininomainen että salasanat ei olisi luokkaa qwerty. Kun turvallisuuteen voitaisiin kiinnittää enemmän huomiota kun nyt ala-asteella käydään opettelemaan koodauksen alkeita. Toki tämäkin tärkeää mutta mun mielestä turvallisuus on nyt juuri erittäin tärkeä asia IOT laitteiden lisääntyessä ,laitteiden oletussalasanat jne.
Se salasanan vaihtopakotus voisi mennä niinkin, että ensiksi sivusto huomauttaa kirjautumisen yhteydessä 2-3 kertaa että alkaa olla pakko vaihtaa ja ehdottaa vaihtoa. Kunnes se 3 kirjautumis kerta sitten pakotetaan vaihtamaan sillä muuten sivuston käyttö ei onnistu ellei salasana vaihdu. Tämä voisi tapahtua rekisteröintihetkestä n. vuoden välein ? Alkuun tuokin kyllä alkaisi vituttaa mutta kyllä sitä tottuis tuohon käytäntöön. Sitten pitäisi olla myös se valvonta että salasana olisi oikeasti riittävän vahva joka sisältäisi erikoismerkeistä isoihin ja pieniin kirjaimiin sekä numeroihin ja riittävän monta merkkiä. Jos tuota ei ole samassa yhteydessä, alkaa vaihtaminnen vituttamaan niin paljon että se salasana vaihdetaan vaan nopsaa jatkaakseen sivuston käyttöä...
Kylkeen vielä kaksvaihetunnistautuminen niin varmasti tällä ja ensi vuosikymmenellä on riittävästi tehty omien tilien suojaamiseksi.
Täysin varmaa keinoa kun ei ole olemassa niin sen kanssa on vain elettävä, mutta näitä asioita yritän ainakin omille lapsille opettaa nyt jo miten tärkeitä nämä riittävän vahvat salasanat ovat esimerkiksi peleissä. Onneksi pelit on menny siihen että online peliä et voi käynnistää ellei päivitykset ole ajan tasalla. Vieläkun laitteet pakottaisi huolehtimaan riittävän hyvästä salasanasta niin oltais ihan hyvällä mallilla.
MD5 + suola ei todellakaan ole turvallinen. MD5 on liian nopea algoritmi, eikä sitä ole tarkoitettu salasanojen kanssa käytettäväksi.
Esim. bcrypt, scrypt, argon2 ovat hyviä algoritmeja. Jos uutta projektia aloittaa, niin argon2 on se, jonka itse valitsisin. Se on todella helppokäyttöinen verrattuna esim. scryptiin, koska parametreja ei tarvitse itse säädellä.
Tämä hash-funktioiden haukkuminen turvattomiksi ilman oikeita perusteita on mielestäni liiallista hifistelyä.
MD5 + suola on edelleen ihan siedettävän turvallinen, etenkin jos on vielä oikeaoppisesti käyttäjäkohtainen suola. Sivustokohtaisen suolan kanssakin tullee toimeen jos kyse on normaali verkkosivu ilman maksutoimintoja.
(MD5 ilman suolaa on jo sitten paljon ongelmallisempi, mutta ei toki aivan toivoton sekään.)
Toki, koska uutta sivustoa käyttöönottaessa vaiva on usein minimaalinen, kannattanee valita joku noista raskaammista tiivisteistä.
Itse toki olisin varovainen liian uuden funktion käytössä. Kun noista voi (periaatteessa) löytyä oikeita haavoittuvaisuuksia, siis jolla pääsisi eroon siitä tiivistemäisyydestä. Tämä ei toki ole kovin todennäköistä enää edes tuolle argon2:lle (poislukien ne tunnetut, ja täysin harmittomat muutama heikkous).
Samoin tässä salasanakäytössä (salasanat lähtökohtaisesti 56 merkkiä tai alle) MD5 ei omaa tunnettuja teoreettisia haavoittuvaisuuksia.
Salasanoja ei murreta tekemällä kirjautumisyrityksiä palveluun vaan lähes aina krakkerilla on lista käyttäjätunnuksista ja salasanatiivisteistä. Yksinkertaistettuna, krakkeri laskee tiivisteitä eri syötteillä ja vertaa laskettua tiivistettä hänellä olevaan listaan tiivisteistä. Jos laskettu tiiviste löytyy listasta, hän tietää kyseisen käyttäjän salasanan.
Tätä hommaa tosiaan vaikeuttaa huomattavasti jos listassa olevat tiivisteet ovat laskettu jollain moderneista algoritmeistä, jotka ovat tarpeeksi työläitä laskea.
Pikaisesti kurkattuna yhdellä Nvidia GTX 1080 kortilla pystyy laskemaan 25 miljardia MD5-tiivistettä sekunnissa tai 13000 bcrypt-tiivistettä sekunnissa. Lähde: 8x Nvidia GTX 1080 Hashcat Benchmarks
Jep. Ja puoli vuosikymmentä vanha prosessorikin pääsee ~1 Ghash/s (kunhan optimoi sen laskun).
Mutta, siis jos salasanat ovat edes kohtalaisia, tämä ei ole mitenkään erityisen toimiva tapa niitä perata.
Toki enää joku 8 merkin satunnaissalasana ei sitä ole: alarajana 86 merkin aakkosto, 8 merkkiä antaa 3 × 10^15 salasanavaihtoehtoa... eli vain reilun vuorokauden yhdellä näytönohjaimella.
Toki, jos ne suolat on käyttäjäkohtaisia, niin käytännössä tämä on oikein riittävä suoja. Laskenta-aikavuorokausi per käyttäjä tulisi aika kalliiksi jos nyt kyseessä ei ole vaikka pankkipalvelu.
Tätä minä en ole vielä ymmärtänyt, miksi hyvä ja ainoastaan yhdessä palvelussa käytössä oleva salasana pitäisi säännöllisesti vaihtaa? Jos se on vaarantunut, niin silloin säännöllinen vaihto on kuitenkin myöhässä.
Mä ajattelen tätä asiaa enemmän, älkää loukkaantuko mutta "tavallisen" ihmisen kannalta jonka tietokoneen käyttö on lähinnnä verkkopankki asiointia tai verkkokauppa ostosten tekeminen tai uutisten lukeminen netissä. Se määrä mikä esim io-techillä lukee on toki iso joukko, mutta silti niin pieni osa suomen väestöstä. Ja tämä pieni joukko io-techillä osaa kyllä rekisteröityessään kertoa tarpeeksi vahvan salasanan, mutta miten tämä saatais ihan koululaisille jo opetettua , että se tilanne salasanojen kanssa olisi esim 10 vuoden päästä niin rutiininomainen että salasanat ei olisi luokkaa qwerty. Kun turvallisuuteen voitaisiin kiinnittää enemmän huomiota kun nyt ala-asteella käydään opettelemaan koodauksen alkeita. Toki tämäkin tärkeää mutta mun mielestä turvallisuus on nyt juuri erittäin tärkeä asia IOT laitteiden lisääntyessä ,laitteiden oletussalasanat jne.
Se salasanan vaihtopakotus voisi mennä niinkin, että ensiksi sivusto huomauttaa kirjautumisen yhteydessä 2-3 kertaa että alkaa olla pakko vaihtaa ja ehdottaa vaihtoa. Kunnes se 3 kirjautumis kerta sitten pakotetaan vaihtamaan sillä muuten sivuston käyttö ei onnistu ellei salasana vaihdu. Tämä voisi tapahtua rekisteröintihetkestä n. vuoden välein ? Alkuun tuokin kyllä alkaisi vituttaa mutta kyllä sitä tottuis tuohon käytäntöön. Sitten pitäisi olla myös se valvonta että salasana olisi oikeasti riittävän vahva joka sisältäisi erikoismerkeistä isoihin ja pieniin kirjaimiin sekä numeroihin ja riittävän monta merkkiä. Jos tuota ei ole samassa yhteydessä, alkaa vaihtaminnen vituttamaan niin paljon että se salasana vaihdetaan vaan nopsaa jatkaakseen sivuston käyttöä...
Kylkeen vielä kaksvaihetunnistautuminen niin varmasti tällä ja ensi vuosikymmenellä on riittävästi tehty omien tilien suojaamiseksi.
Täysin varmaa keinoa kun ei ole olemassa niin sen kanssa on vain elettävä, mutta näitä asioita yritän ainakin omille lapsille opettaa nyt jo miten tärkeitä nämä riittävän vahvat salasanat ovat esimerkiksi peleissä. Onneksi pelit on menny siihen että online peliä et voi käynnistää ellei päivitykset ole ajan tasalla. Vieläkun laitteet pakottaisi huolehtimaan riittävän hyvästä salasanasta niin oltais ihan hyvällä mallilla.
Miksi ottaa käyttöön vaihtopakko? Se on tutkitusti huono käytäntö. (Josta ollaan onneksi hiljalleen luopumassa monissa paikoissa. Esim. taisi juuri pudota tulevassa toukokuun koontiversiossa Windows-pohjaisen monen koneen työympäristön vakioasetuksista pois tuo vaihtopakko. Toki sen saa edelleen päälle, mutta nyt se pitää käsin sieltä ylläpidon valita päälle.)
Hyvästä salasanasta huolehtiminen onnistuisi muuten mielestäni paremmin, jos sanasta ”salasana” luovuttaisiin. (Ja ihmisiä rohkaistaisiin käyttämään esim. myös sitä välilyöntiä.) Kaikkein tyhmin esimerkki mitä olen nähnyt on ne ”lyhennetyt lauseet” -salasanat. Siis, oleellisesti vaikeutetaan muistamista, mutta helpotetaan raa'alla voimalla murtamista... (välilyöntien poisto vähentää sitä entropiaa, kun useampi mietelause johtaa samaan salasanaan).
Toki, heikkojen salasanojen tunnistus kannattaa toteuttaa. Mutta näissä pitää varoa: moni kieltomekanismi mitä olen nähnyt esim. hylkää liian hyvät salasanat, kun on rajattu esim. maksimimäärä yhtä kirjainta + toisteisuus + noin miljoona muuta mukamas hyvää rajoite-ehtoq (joka sitten käytännössä näkyy siinä, että palvelu tiputtaa 20+ merkin satunnaissalasanan pois liian heikkona).
Hyvä kattava kirjoitus @L2K2
Mikä ois korvaava sana salasanalle ? Salalause ? Salajono/Salamerkistö ? Tunnistautuminen : ?
Olen samaa mieltä että siitä pitäis luopua, ja tilalle keksiä joku standardi vakio korvaava sana kaikkialle.
@L2K2
Toki, heikkojen salasanojen tunnistus kannattaa toteuttaa. Mutta näissä pitää varoa: moni kieltomekanismi mitä olen nähnyt esim. hylkää liian hyvät salasanat, kun on rajattu esim. maksimimäärä yhtä kirjainta + toisteisuus + noin miljoona muuta mukamas hyvää rajoite-ehtoq (joka sitten käytännössä näkyy siinä, että palvelu tiputtaa 20+ merkin satunnaissalasanan pois liian heikkona).
Mutta ei toteuta tuota niin kireäksi, koska hyvä sala"lause" voi olla lyhyempi kunhan sisältää vaikka sen välilyönnin ja kaikenlaista muuta sekalaista. 10 merkin salalause on jo aika hyvä jos siinä numeroa isoa ja pientä sekä erikoismerkkejä sekä vielä välilyönti ? Ei ehkä, 10 merkkinen mutta 15 merkkinen on jo melko varmasti riittävän vahva ?
Mikä ois korvaava sana salasanalle ? Salalause ? Salajono/Salamerkistö ? Tunnistautuminen : ?
Olen samaa mieltä että siitä pitäis luopua, ja tilalle keksiä joku standardi vakio korvaava sana kaikkialle.
Joskus omille sivuille toteutin javalla semmoisen salasanageneraattorin mikä teki salasanan ja ohjeisti samalla millon on hyvä salasana. Testiä ei käytännössä päässy läpi jos ei salasanaan ollu lisänny näitä kaikkia vaadittuja kohtia, esim pieni kirjain, iso kirjain, erikoismerkki ja numero. Välilyönti on tuohon oiva lisä kyllä. Googlestahan noita salasanageneraattoreita löytää mutta mun mielestä ne on vähän turhan hepposia...Tai ehdottaa vähä turhan kevyitä juttuja ainakin osa. Noista salasanageneraattoreista ei sitten tiedä tallentaako ne johonkin näitä luotuja salasanoja että älkää käyttäkö suoraan niiden luomia salasanoja...
Taidan lyödä uudelleen tulille tuon oman salasanageneraattorin , oli sillä ihan kiva leikkiä kun näitä salasanoja keksi itelleen...
Mä ajattelen tätä asiaa enemmän, älkää loukkaantuko mutta "tavallisen" ihmisen kannalta jonka tietokoneen käyttö on lähinnnä verkkopankki asiointia tai verkkokauppa ostosten tekeminen tai uutisten lukeminen netissä. Se määrä mikä esim io-techillä lukee on toki iso joukko, mutta silti niin pieni osa suomen väestöstä. Ja tämä pieni joukko io-techillä osaa kyllä rekisteröityessään kertoa tarpeeksi vahvan salasanan, mutta miten tämä saatais ihan koululaisille jo opetettua , että se tilanne salasanojen kanssa olisi esim 10 vuoden päästä niin rutiininomainen että salasanat ei olisi luokkaa qwerty. Kun turvallisuuteen voitaisiin kiinnittää enemmän huomiota kun nyt ala-asteella käydään opettelemaan koodauksen alkeita. Toki tämäkin tärkeää mutta mun mielestä turvallisuus on nyt juuri erittäin tärkeä asia IOT laitteiden lisääntyessä ,laitteiden oletussalasanat jne.
Se salasanan vaihtopakotus voisi mennä niinkin, että ensiksi sivusto huomauttaa kirjautumisen yhteydessä 2-3 kertaa että alkaa olla pakko vaihtaa ja ehdottaa vaihtoa. Kunnes se 3 kirjautumis kerta sitten pakotetaan vaihtamaan sillä muuten sivuston käyttö ei onnistu ellei salasana vaihdu. Tämä voisi tapahtua rekisteröintihetkestä n. vuoden välein ? Alkuun tuokin kyllä alkaisi vituttaa mutta kyllä sitä tottuis tuohon käytäntöön. Sitten pitäisi olla myös se valvonta että salasana olisi oikeasti riittävän vahva joka sisältäisi erikoismerkeistä isoihin ja pieniin kirjaimiin sekä numeroihin ja riittävän monta merkkiä. Jos tuota ei ole samassa yhteydessä, alkaa vaihtaminnen vituttamaan niin paljon että se salasana vaihdetaan vaan nopsaa jatkaakseen sivuston käyttöä...
Kylkeen vielä kaksvaihetunnistautuminen niin varmasti tällä ja ensi vuosikymmenellä on riittävästi tehty omien tilien suojaamiseksi.
Täysin varmaa keinoa kun ei ole olemassa niin sen kanssa on vain elettävä, mutta näitä asioita yritän ainakin omille lapsille opettaa nyt jo miten tärkeitä nämä riittävän vahvat salasanat ovat esimerkiksi peleissä. Onneksi pelit on menny siihen että online peliä et voi käynnistää ellei päivitykset ole ajan tasalla. Vieläkun laitteet pakottaisi huolehtimaan riittävän hyvästä salasanasta niin oltais ihan hyvällä mallilla.
Tulevaisuuden kannalta ajateltuna yleensäkin tietoturvaa olisi mielestäni hyvä opettaa lapsille ajoissa, ei mitään liian hebreaa vaan sellaista ikätasoon nähden sopivaa.
Tosin itsellä on jotenkin sellainen tunne että pitkällä aikavälillä se perinteinen käyttäjätunnus ja salasana autentikointi on väistymässä uudenpien menetelmien tieltä.
Tuo ajan piteminen oli kyllä hyvä idea jos väärinkirjoitetun jälkeen aina aika pitenisi muutaman sekunnin kerrallaan(ja jos vaikka 10x laitat väärin ip lukkoon 5tunniksi tms).
Aivan, tuota en ajatellukkaan. Paitsi että helposti jää ip osoite nalkkiin jos jää johki logeihin kun väärälle tilille yrittää kirjautua, mutta tässäkin se tulee se voi käyttää proxyjä ja vpn palveluita taas... Onpa se nyt vaikeeta Kait se täytyy tunnustaa että io-techin ja kaikkialla muuallakin käytössä oleva kombinaatio käyttäjätunnus/sala"sana" vaan on toimivin yhdistelmä.. plus kaksvaihetunnistautuminen ilman mitään turhia lisäkikkareita. No edes tuo salasanan "opastus" (tilinluonti vaiheessa/salasana vaiheessa) vois olla kyllä aika kova että vältyttäis ainakin näiltä ihan liian heikoilta salasanoilta..
Onko tämä joku vitsi vai millä motiivilla levittelet näitä juttuja?
Tuossa on hyvä blogipostaus, joka kannattaa oikeasti lukea. Se on jo miltei 10 vuotta vanha, mutta valaisee asiaa mielestäni erittäin hyvin, joten myös maallikotkin ymmärtävät mistä on kyse. How To Safely Store A Password | codahale.com
Vrt. lihavointini alkuperäisessä viestissä. En siis usko, että tuon vakiotiivistefunktion korvaamiseen käytetty aika on järkevää normaalille sivustolle, vrt. ulkoasun ja sisällön tuotanto. Turvallisuus valitaan oletettavien uhkien – ja siten epäsuorasti sen käyttötarkoituksen – mukaan!
Normaalilla sivulla MD5-pohjainen tiiviste on aivan riittävä pitämään hyvän tai kohtalaisen salasanan käyttäjät ”turvassa” riittävän kauan myös offline-hyökkäystä vastaan. (Tuo blogipostauksesi käyttää ihan tahallaan esimerkkinä kuusimerkkistä (6) salasanaa ilman erikoismerkkejä tai edes isoja kirjaimia! Vuosikymmenen tekninen kehitys ei tätä pahemmin muuta... koska eksponentiaalisesti kasvaa se laskenta-aika sen pituuden mukana.) Ja, ne oikeasti huonot salasanat ”murtuvat” hitaallakin tiivisteellä melko nopeasti (siitä salasanojen TOP1000-listasta kokeilemalla saa ison määrän toimivia tunnuksia).
Toki nykyään tehoa on enemmän. Siksi annoin itse sentään tuota hieman realistisemman numeron laskenta-aikaa (ja salasanan pituutta). Mutta, edelleen turvallisuustaso käyttötarkoituksen mukaan.
Vrt. vaikka viranomaisvaatikuksena eiDAS yhdenmukaisuus, vähintään kaksi kolmesta pitää olla: ”Todentamistekijät voidaan jakaa seuraaviin luokkiin, joita tarkastellaan lähemmin seuraavilla sivuilla:
• tiedossaoloon perustuvat todentamistekijät
• hallussapitoon perustuvat todentamistekijät
• luontaiset todentamistekijät.
Eri luokkiin kuuluvia todentamistekijöitä voidaan myös yhdistää; esimerkkinä tästä on salaustunniste joka on suojattu sormenjälkitiedolla tai PIN-koodilla. Useampaa kuin yhtä eri luokkiin kuuluvaa todentamistekijää hyödyntävää tunnistamismenetelmää kutsutaan useaan tekijään perustuvaksi menetelmäksi.” ( https://www.kyberturvallisuuskeskus...es/media/file/LOA_Guidance_Final_suomeksi.pdf )
Ei auta ns. parempikaan tiiviste tuohon vaatimukseen. Ja, silti tuolle tietää-osalle ei ole asetettu muotovaatimuksia.. (PIN-koodia ei saa offline-hyökkäyksen kestäväksi millään tiivisteellä.)
Ovatkohan ajatelleet oikeasti, vai vaan halunneet teknologiaa teknologian vuoksi.
(Myös, onko se offline-hyökkäys se sivustosi oletettu isoimman riskin hyökkäysvektori. Eli, onko ne muut tehokkaammat tavat estetty tarpeeksi hyvin?)
Eiköhän se ole heille jo moneen kertaan kerrottu. WordPress elää (syystäkin) aika kyseenalaisessa maineessa juuri jatkuvien tietoturvaongelmiensa takia.
Toisin sanoen: se, että WordPress käyttää MD5-algoritmia salasanojen suojaamiseen, ei tee MD5:stä hyvää algoritmia salasanojen suojaamiseen.
Kyllä se tietoturva pitää asianmukaisesti hoitaa olipa sivusto siten mikä hyvänsä. Asianmukaista on käyttää salasanojen suojaamiseen siihen tarkoitettua algoritmia, eikä mitään muita algoritmeja, eikä etenkään mitään omia viritelmiä.
Ei pidä paikkaansa.
Jos nyt joku lukee tätä ketjua ja oikeasti miettii, että mitä algoritmia käyttäisi, niin käyttäkää jotain salasanojen suojaamiseen tarkoitettua algoritmia, joita mainittiin aiemmin. MD5, SHA1, SHA2 eivät ole sellaisia olipa suola sitten millaista hyvänsä, sillä ne on suunniteltu ihan eri käyttötarkoitukseen.
Hoitamalla tietoturvan välinpitämättömästi teette vain karhunpalveluksen käyttäjille. Hyökkääjää tuskin kiinnostaa teidän harrastesivuston tunnukset, mutta koska valitettavan monet käyttäjät käyttävät samaa salasanaa monessa eri palvelussa, on järkevää kokeilla murrettuja salasanoja eri palveluihin, kuten esimerkiksi sähköpostiin.
Tutkimuksen mukaan on yleistä freelancer-kehittäjien ja opiskelijoiden keskuudessa, että tietoturvaa ei osata hoitaa kunnolla. Tutkimuksesta selviää esimerkiksi, että todella moni edellä mainituista luulee, että esim. MD5 on hyvä algoritmi salasanojen suojaamiseen.
Riittävä vs. hyvä. Valitaan ne adjektiivit sopivasti, ja MD5 on oikein kelvollinen. Täydellisyyden tavoittelu on usein tarpeetonta.
Myös, linkittämässäsi jutussa ongelmana ei ole niinkään se MD5 käyttäminen (kuin esim. ihan ehta selkotekstinä tallentaminen, tai vaikka base64-enkoodaus, eli oleellisesti selvänä tekstinä salasanojen tallentaminen). MD5 + (oikeaoppinen) suola (+ iteraatioita) saisi tuossa noiden asteikossa oikein kivat pisteet (vaikka se noiden mielivaltainen 160 bitin tiivistepituus ei siinä toteudu).
Samoin, jos tehdään oikeasti ison liikenteen sivustoa, niin noita raskaita tiivisteitä ei välttämättä voida käyttää (koska serverin kuorma olisi suuri). Tuohonkin on toki ratkaisut (ei tiivistettä, vaan salasanojen salaus ja sen salausavaimen taltiointi muualle kuin siihen tietokantaan). Joku tietoturvahutkija toki voi laittaa sen ”lasketaan tätä tiivistettä sekunti tehokkaalla serverilläni jotta kukaan ei raa'alla voimalla murra edes viisimerkkistä salasanaa klusterilla”, mutta koettapa myydä tuo ylläpitäjälle jonka sivuilla on ruuhka-aikaan tuhansia käyttäjiä. (Toki tässä tuo muisti-intensiivinen tiiviste on kiva, koska se on suhteessa nopeimmillaan kalliilla palvelinraudalla eikä esim. ”halvoilla” pienen sähkönkulutuksen erikoistuneilla laskupiireillä.)
Toki sitä itse ihmettelen, että jos tietoturvaparanoidit (kuten osa noista suosituksien laatijoista) haluavat haukkua tunnettuja ja riittäviä menetelmiä, niin miksi näissä ei sitten koskaan ehdoteta sentään sitä ”ja” operaatiota noihin vanhoihin tiivisteihin. (Koska itseäni hieman hirvittäisi esim. olla ottanut käyttöön uutuudenkiiltävä tiiviste (jolle voi löytyä ihan oikeita heikkouksia) vanhan ja tunnetusti huomattavan määrän kryptoanalyysiä kestäneen tilalle.)
Siis, että tallennetaan ”[suola]+MD5/SHA256([salasana]+[suola])+uusi_hieno_ja_hidas_tiiviste([salanana]+[suola])”. Nyt saisi myös sen takeen siitä klassisen menetelmän (todennäköisemmästä) kestosta oikeita haavoittuvuuksia vastaan (ts. nopeampia kuin raa'asti kokeilla läpi yritteitä).
Ja, käyttäjän tyhmyyttä vastaan suojautuminen, no... sille tielle kun menee, niin sanotaanko salasanan olevan pienin murhe. (Tämän ratkoisi esim. vaatimalla blogiin kommentoivilta riittävän huonoja salasanoja jotta ne eivät voi olla minkään oikean palvelun salasanoina. ;-) ) Melko kuvaavaa tuossa on, että 32 miljoonasta salasanasta alle 14 miljoonaa oli uniikkeja... (ja siis tuossa oli kokonaan suolaton MD5, vahingossa tallennettuna, vaikka itse tiivisteenä oli bcrypt). Montakohan hyvää salasanaa siihen murrettuun 11 miljoonaan mahtuu? 11 + 14 < 32...
MD5 ei ole kelvollinen, oikein kelvollinen, hyvä tai edes riittävän hyvä algoritmi salasanojen suojaamiseen; siitä ei pääse yli eikä ympäri tekipä sitten millaisia omia virityksiä tahansa tai käyttipä millaista suolaa tahansa.
Ei ole pakko käyttää sellaisia parametreja, joilla tiivisteen laskemiseen menisi sekunti aikaa. Missään implementaatiossa tuskin edes on sellaisia oletuksena asetettu. Jos oletusparametrit eivät syystä tai toisesta kelpaa, niin ne voi säätää omaan järjestelmään sopiviksi, kuten @Flogestoni tuolla aiemmin kertoi tehneensä.
Tuossa nyt ei ole mitään järkeä. Koko salasanojen suojaamisen idea on se, että sitä ei voida tehdä toisin päin, eivätkä ne salasanat näin ole edes ylläpidon tiedossa.
Tämäkään ei ollut omaa keksintöä, vaan oikean maailman pahuutta. (Ok. oikean maailman pahuutta on se kun tunnistaa ison valtiollisen toimijan käyttävän todennäköisesti edelleen palvelussa X selkotekstitallennusta, tai ainakin sen jäänteenä seuranneita salasanasääntöjä.)
Toki oikea tapa nopeaan vertailuun olisi sopiva HMAC, jossa ylläpitokaan ei pääse käsiksi salasanaan. (Mutta jossa voidaan silti käyttää nopeaa tiivistettä ilman että tarkistussummista yksinään voi edes raa'alla voimalla murtaa salasanoja.)
Nyt siis vertailuun ja murtamiseen tarvitaan sekä se N bittinen salainen avain, että se laskettu tarkistussumma (joka käyttäytyy melkein kuin tiiviste).
Ja, vaikka jos tuo avain vuotaa, niin silti tämä olisi edelleen noiden vanhojen kohtalaisten tiivisteiden tasoa. Ts. hyvät salasanat eivät murru.
Joo, ei pitäisi ehdottaa foorumipostauksessa uusia menetelmiä. Tuo oli oppikirjaesimerkki kryptografisesta ”TAI” operaatiosta. Tämä selittänee miksi moista ei ole.
Ensinnäkään "uusi hieno hidas tiiviste" (eli tässä tapauksessa bcrypt) ei tarvitse suolaa, koska suolaus sisältyy jo siihen algoritmiin itseensä, se toimii siis oikeaoppisesti käytettynä näin: bcrypt(salasana). Omasta suolaamisesta ei ole mitään hyötyä.
Tarvitsee se. Se että bcrypt kirjasto piilottaa tämän sinulta ei tarkoita itse algoritmin tulevan toimeen ilman sitä!
Suola ei voi olla oikeaoppisesti osa tiivistealgoritmia, koska suolan tulee olla käyttäjä- ei salasanakohtainen!
Vertailukutsuhan on siis toki bcrypt (salasana, kohdemerkkijono), missä kohdemerkkijono on oleellisesri ”hintaparametri”+ ”suola” + ”tiiviste”.
Ideana toki on estää koodarin tyhmyys, eli lähestulkoon pakottaa käyttäjäkohtaisen suolan käyttöön. (Tätä toki voi kiertää, mutta se tarvitsee aktiivista toimintaa.)
Tuo paljas kutsu tuottaa joka kerta uuden suolan. Ts. se on tavallaan satunnaislukugeneraattori, ei tiiviste. Toki sitä ei kannata käyttää satunnaislukuihin, monestakaan syystä.
Toisekseen tuo sinun ehdotelma vain heikentää suojausta, koska tuossa tapauksessa murtajalle riittää vain MD5-osuuden murtaminen, jollon salasana selviää jo siitä, eikä bcrypt-osuutta edes tarvitse arvailla. Tuo on siis sama, kuin sinulla olisi pelkästään MD5(salasana . suola).
Tämä nyt taas osoittaa sen, että omia virityksiä ei pidä tehdä, koska kryptografia ja sen soveltaminen on vaikeaa ja se tulee menemään pieleen jos sen tekee itse. Kannattaa luottaa sen sijaan hyviin tutkittuihin menetelmiin. Jos argon2 on omaan makuun liian uusi, niin ihan hyvin voi käyttää vielä bcryptiä, joka julkaistiin jo 1999.
A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.
-- Kerckhoffs's principle
Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break.
-- Schneier's Law
Mutta, joo, MD5 on noin äärettömän paljon parempi kuin ei mitään. MD5 + oikeaoppinen suola on enemmän kuin käyttäjämäärä verran vielä tästä parempi.
Laskenta-aikatavoitteesta riippumatta bcrypt on vielä parempi, toki jopa ns. naurettavan alhaisilla ”hinnoilla” kuten 6. (Koska MD5 laskenta-aika nanosekuntiluokkaa.. ja tuokin on vähintään mikrosekunteja.)
PS. Lisäesimerkkejä, oletuslaskenta-aika yhden kirjaston vakioparameteilla 0,1 sekuntia: bcrypt
Eikä pitänyt. Se, että opiskelija, jota pyydetään tallentamaan salasana tietokantaan turvallisesti, valitsee MD5-algoritmin ei johda siihen, että MD5 olisi hyvä algoritmi salasanojen suojaamiseen.
Ei pidä paikkaansa, mihin nämä väitteet edes perustuvat?
Suola on ihan määritelmällisesti uniikki (eli salasanakohtainen), ei käyttäjäkohtainen, joten se voi olla osa salasanojen suojaamiseen käytettävää algoritmia. Jos käyttäjä vaihtaa salasanaa, on myös suola vaihdettava. Samaa suolaa ei saa uudelleenkäyttää.
Salt (cryptography) - Wikipedia
Pippuri on taas sitten eri asia eikä salasanojen suojaamiseen käytettävät algoritmit sitä pysty automaattisesti tarjoamaan. Pippuri on ohjelmistokohtainen ja sen ideana on se, että jos murtautuja saa tietokantadumpin haltuunsa, on se käyttökelvoton ilman konfiguraatiotietostoa (tai muuta paikkaa johon pippuri on säilötty).
Pepper (cryptography) - Wikipedia
Älä esitä tyhmää jos et sitä ole, tai yritä väittää linkkejäsi eri linkeiksi kuin mitä ne ovat.
1. Linkittämäsi tutkimus ei ole se opiskelijoilla tehty, vaan tuo jatko-osa aiheesta, jossa ostettiin koodia rahaa vastaan verkosta. Saatiin hieman parempi tulos kuin opiskelijoilla, mutta ei mitenkään erityisen hyvä.
Ohessa vielä se samojen tutkijoiden aikaisempi tutkimus opiskelijoilla, jossa myös tuon myöhemmän pisteytyskäytäntö on kerrottu selvemmin: Why Do Developers Get Password Storage Wrong?
2. Molempien pisteytyksessä oikein toteutettu (mutta MD5-tiivistettä käyttävä) tarkistus on laskettu vähintään kohtalaiseksi.
Hash, +1 piste. (MD5 kelpaa tässä yhtä hyvin kuin mikä tahansa uudempi.)
Hash length at least 160 bits, +1 piste. (Lähes mikä tahansa uudempi tiiviste kuin MD5, myös nopeat ja käytännössä yhtä ”risat” kuten SHA-1.)
Salt, +1 piste. (Tässä toki MD5 käyttäjä joutuu itse koodaamaan, vrt., OpenBSD-tyylinen bcrypt-rajapinta (viestini lopussa).)
Iteration count, +0,5 tai +1 pistettä. (Tämä on annettu vain PBKDF2 tai bcrypt-toteutuksille, ja tuolle bcrypt on vaadittu vain ihan siedettävä 10 millisekunnin luokkaan laskenta-ajan nostava kerroin – omalla koneellani ja OpenBSD:n C-toteutuksella nopeasti testaten.)
Memory hard hash function, +1 piste. (Oleellisesti scrypt tai Argon2, kukaan ei saanut kummassakaan tutkimuksessa tätä. Jälkimmäisessä eivät pitäneet tätä pistettä enää laskuissa tästä syystä.)
Random salt generation, +1 piste. (Oleellisesti siis oikea ohjelmointitapa.)
Salt at least 32 bits, +1 piste. (Oleellisesti siis oikea ohjelmointitapa.)
Oikein tehty MD5 saa näistä: hash + salt + random salt + salt at least 4 bytes, neljä pistettä kuudesta (teoriassa seitsemästä, mutta jälkimmäisessä tuo viimeinen piste poistettiin koska sitä ei koettu mielekkääksi vaatia).
Toki missään ei puhuta mikä on huono tai hyvä pistemäärä. Mutta, siis ei tuota voi pitää noiden kriteereillä turvattomanakaan.
3. Sitten tuohon suolaan: suola on käyttäjäkohtainen satunnaismerkkijono! Ei siis salasanakohtainen siinä mielessä kuin esitit sillä hypoteettisella ”bcrypt”-funktiollasi (jossa syötteenä oli vain salasana)...
Suola ei missään nimessä ole salasanan funktio, noin matemaattisesti. Muutoin sitä suolaa ei olisi! Käytetään niitä oikeita termejä, jos halutaan nillittää muille.. (Toki käyttäjäkohtainenkin on hieman väärä sana, koska suola ei ole ideaalisesti käyttäjän funktiokaan, vaan satunnainen merkkijono. Mutta esim. käyttäjän UUID on kohtalaisen hyvä ja yleisesti käytetty suola (jos se on valmiiksi kiva satunnainen merkkijono, mutta jos taas esim. vaikka ylläpidon tunnuksen UUID on aina 0, niin se on aika harvinaisen huono suola kun sen voi tietää etukäteen ennen murtoa ja laskea valmiiksi niitä arvauksia). UUID ei toki aivan yhtä hyvä kuin kunkin käyttäjän (esim. salasanatiivisteen) yhteyteen tallennettava henkilökohtainen satunnaismerkkijonosuola jota vaihdetaan aina tarvittaessa. Siksipä tuo paras tapa on tosiaan tehdä lisää suolaa aina uusi salasana tiivistettäessä. Estää virheitä.)
Suolan voi siis vaihtaa määräajoin, esim. aina vaikkapa salasanaa vaihdettaessa, tai periaatteessa vaikka useamminkin (sen voi periaatteessa vaihtaa aina kun käyttäjä kirjautuu sisään). Mutta, se ei ole mikään pakko (ja jälkimmäisessä ei ole yleensä mitään järkeä). Ideana on siis olla käyttäjäkohtainen osa tiivistettävää merkkijonoa, jotta ei voi murtaa useampaa tiivistettä per arvaus – tai edes selvittää onko joillain kahdella käyttäjällä sama salasana. Puhumattakaan, että voisi rakentaa sateenkaaritauluja ennakkoon.
Jos pitää vääntää rautalangasta, niin väännän sitten:
Josta nähdään heti kuinka se suola ei ole salasanan funktio, uuden salasanan tiivistämiskutsu on tuossa ”hash_string = bcrypt.hashpw(password, bcrypt.gensalt(rounds = 12, prefix = b"2b"))”.
Parempi rajapinta olisi toki estää kokonaan käyttäjää määrittelemästä käsin suolaa. Tämä estäisi suolan jakamisen käyttäjien välillä tallentamalla tuon ”gensalt”-funktion paluuarvo, ts., koodausvirheen. Taustalla olevan OpenBSD-koodin uudempi rajapinta näyttäisi noin tekevän, kun sen ”crypt_newhash” ottaa vastaan vaan kierrosmäärän parametrinaan: crypt_checkpass(3) - OpenBSD manual pages .
Tuo kierrosmäärä on hieman hassusti tuossa suolan luonnissa, mutta se on siinä vain siksi, että tuo kierrosmäärä tallennetaan siihen suolan eteen laitettavaan ”prefix”-merkkijonoon. Se ei vaikuta itse suolaan, joka on vaan satunnaismerkkijono satunnaislukugeneraattorilta.
Ja vertailukutsu ”bcrypt.checkpw(password, hash_string)”, missä tosiaan ”hash_string = prefix + salt + hash”. Eli se suola pitää sinne tiivisteelle välittää... Ei ole kuvaamaasi taikafunktiota ”bcrypt(password)” joka tekisi tuon tiivisteen.
Suola on siis käyttäjäkohtainen, ei salasanakohtainen. Sama salasana ei tietenkään saa saada eri käyttäjillä samaa suolaa (kuin korkeintaan satunnaisesti, mutta siksi sitä suolaa pitää olla tarpeeksi paljon).
Suola pitää generoida jokaiselle salasanatiivisteelle erikseen. Samaa suolaa ei saa käyttää uudelleen eri tiivisteiden kanssa. Tässä mielessä suolan pitää olla täysin uniikki. Ei siis pelkästään käyttäjäkohtainen, vaan se pitää vaihtaa myös silloin kun käyttäjä vaihtaa salasanaa.
Siis esim. että mikä tekee UUID:stä huonon suolan, tai miksi saman käyttäjän suolaa ei saisi samalla käyttäjällä uudelleenkäyttää.
(Bcrypt ja kumppanit eivät toki uudelleenkäytä. Suurin syy toki lienee se, että tällä tavoin niiden vaihtaminen perinteisen suolaamattoman tiivisteen tilalle on mahdollisimman helppoa. Sen kun vaan vaihtaa sen yhden rivin koodia salasanan vaihtorutiinin ja tunnistautumisrutiinin kohdalla. Tai, no, jälkimmäisessä yleensä pari riviä. Piilotetaan suolan käsittely niin koodarin ei tarvitse käsin sitä tehdä joka sovelluksessa erikseen.)
Tämänkaltainen käsin laadittu suola toki yleensä tallennetaan erilliseen tauluun tietokannassa. Samoin tekisi varmaan käsin suolaaja myös satunnaissuolalle (joka on toki, kunhan se vaan on riittävän pitkä) kaikin puolin vähintään yhtä hyvä kuin vaikka jonkun klassinen valinta ”sivusto”+”käyttäjänimi”+”UID” (jossa siis tahallaan on tarpeeksi yksilöiviä asioita estämään törmäykset) tai sitten ihan se “UUID” (oleellisesti rekisteröitymisen yhteydessä laadittu satunnaismerkkijono).
EDIT. Ja, toki tahallaan jätit vastaamatta isoon osaan väitteitä ja poimit valikoiden haluamasi tulkinnan (etkä linkittämäsi artikkelin kirjoittajien tulkintaa) artikkelista.
Toki tiivistevertailu on se missä se suolan käyttäjäkohtaisuus näkyy, juurikin tuosta syystä että ei ole olemassa ns. puhdasta tiivistefunktiota ”bcrypt(salasana)” vaan se suola on sinne tosiaan annettava (vrt. rajapintaesimerkki yllä ja myös sinun rajapintasi salasanavertailu ”bcrypt(salasana, yhdistetty tiiviste suolalla) === true” vs. ”tiivistefunktio(suolattu salasana) === tiiviste)”.
Mielenkiintosia juttuja tuli kyllä kaikilta, olen tätä nyt pureskellu ajan kanssa tässä mutta avaan pikkusen enemmän tuota omaa tarkoitusperää tälle asialle.
Nyt taitaa tietokantaan omilla sivuilla mennä md5 tiiviste ja suolalla. Eli, koska sivusto on vain minun käytössäni ja rekisteröintipakko on jos haluaa enemmän nähdä niin luulen että tämä nykyinen on ihan riittävä kuitenkin. Tietokannasta näen kyllä salasanan(en selkokielisenä), vaan se on semmoinen sekamelska random merkkejä täynnä.
Eli nyt täytyisi vielä katsoa jos vaihdan salasanani niin päivittyykö se myös tietokantaan uudella sekamelska merkkinojolla ? Lisäksi täytyy kokeilla luoda random fake tili ja katsoa että myös sille saa taas oman uniikkinsa sekemateli merkijonon tietokantaan ?
Se miksi teen sen näin, ihan vaan koska koodaustaidot on jossain 0 nurkilla ja koodin seasta sitä vaikeampi paikantaa ja näkeepähän samalla että toimii niinkuin on tarkoitus...Ja tuo siis on vain itselle semmoinen harrastus vain jos sitä oppis joskus enemmän asioista ja minne voin projekteistani tehdä yhteenvetoja sekä muistiinpanoja. Aikanaan toimi vieroitushoitona facelle
Vielä yksi kysymys liittyen salaukseen. Veracrypt vai Truecrypt ohjelma ? Kumpaa kannatat ja miksi ?
Itse siirryin jo veracryptiin koska truecrypti taitaa olla kuollut projekti muttakun tuosta tulee hieman ristiriitaista tekstiä vastaan aina että kumpaa kannattaa käyttää. Ja eikös tuo vera ole truesta jatkoa ?
