Salasanojen salaus tietokantaan millä

Viestiketju alueella 'Internet, tietoliikenne ja tietoturva' , aloittaja Vauhtimursu, 27.04.2019.

  1. Vauhtimursu

    Vauhtimursu

    Viestejä:
    292
    Rekisteröitynyt:
    30.07.2017
    On saanu viime aikoina paljon huomiota kun salasanat löytyy salaamattomina palvelimilta niin pakko kysyä nyt sitten että mikä on hyvä keino ja miksi.

    Mikä salaus on riittävä salasanoille ?

    Entä tuo md5 tiiviste + suolaus ? Käsittäny että se ei olis hirveen turvallinen ?
     
  2. oselotti

    oselotti

    Viestejä:
    331
    Rekisteröitynyt:
    02.11.2016
    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ä.
     
  3. mRkukov

    mRkukov Hrrrr...

    Viestejä:
    4 552
    Rekisteröitynyt:
    17.10.2016
    MD5 on kyllä aikanaan ollut ihan riittävä salasanoille, mutta aika ajanut pahasti sen ohi. Onhan tuolla ikää jo yli 25 vuotta. :)
     
  4. Vauhtimursu

    Vauhtimursu

    Viestejä:
    292
    Rekisteröitynyt:
    30.07.2017
    Kiitos nopeista vastauksista, oli mulla vähä tuommoinen pienoinen käry kyllä tuosta md5 mutta sitäkään vähää ei sitte käryä ole millä sen voi korvata.

    Mutta kiitos !
     
  5. Algron28

    Algron28

    Viestejä:
    1 332
    Rekisteröitynyt:
    17.10.2016
    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.
     
  6. Tuke

    Tuke

    Viestejä:
    33
    Rekisteröitynyt:
    21.10.2016
    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
     
    Stanley H. Tweedle, dot1q, oselotti ja 6 muuta tykkäävät tästä.
  7. Flogestoni

    Flogestoni

    Viestejä:
    13
    Rekisteröitynyt:
    05.09.2018
    Ääni Argon2:lle, vaihdoin duunissa pari vuotta sitten käyttäjien salasanat eräässä Windows-tuotteessamme siihen ilman ongelmia. Siitä saa hyvin säädettyä helpoilla parametreillä rinnakkaisuuden, muistinkäytön ja iteraatioiden lukumäärän avulla omaan käyttötarkoitukseensa sopivan.
     
    oselotti tykkää tästä.
  8. Vauhtimursu

    Vauhtimursu

    Viestejä:
    292
    Rekisteröitynyt:
    30.07.2017
    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...
     
    Viimeksi muokattu: 27.04.2019
  9. Algron28

    Algron28

    Viestejä:
    1 332
    Rekisteröitynyt:
    17.10.2016
    Onko tämän homman nopeuden kannalta väliä onko salasana vaikka "peruna" kuin että se olisi vaikka "Mongol1ala1nenK1kkel1nokkaelä1n"
     
  10. jessenic

    jessenic

    Viestejä:
    318
    Rekisteröitynyt:
    17.10.2016
    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.
     
  11. Vauhtimursu

    Vauhtimursu

    Viestejä:
    292
    Rekisteröitynyt:
    30.07.2017
    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 !
     
    Viimeksi muokattu: 28.04.2019
  12. neko

    neko Make ATK Great Again

    Viestejä:
    1 987
    Rekisteröitynyt:
    18.10.2016
    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):facepalm:
     
  13. Rensu

    Rensu

    Viestejä:
    292
    Rekisteröitynyt:
    17.10.2016
    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ä.
     
    drealz ja neko tykkäävät tästä.
  14. apek

    apek

    Viestejä:
    662
    Rekisteröitynyt:
    02.04.2017
    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.
     
    Vauhtimursu ja neko tykkäävät tästä.
  15. neko

    neko Make ATK Great Again

    Viestejä:
    1 987
    Rekisteröitynyt:
    18.10.2016
    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.
     
    Vauhtimursu tykkää tästä.
  16. Ragnarokkr

    Ragnarokkr "Ei mikään turha jätkä"

    Viestejä:
    153
    Rekisteröitynyt:
    21.12.2016
    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
     
  17. neko

    neko Make ATK Great Again

    Viestejä:
    1 987
    Rekisteröitynyt:
    18.10.2016
    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. :)
     
  18. Vauhtimursu

    Vauhtimursu

    Viestejä:
    292
    Rekisteröitynyt:
    30.07.2017
    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.
     
    Viimeksi muokattu: 28.04.2019
  19. Zyrppa

    Zyrppa

    Viestejä:
    1 064
    Rekisteröitynyt:
    20.10.2016
    Jokainenhan voi ladata Hashcatin ja kokeilla sillä, että miten nopeasti minkäkin salasanan saa brute forcetettua kun käytössä on algoritmi x. Sitten voi vielä luoda sanakirjat ja kokeilla miten se vaikuttaa asiaan.
     
  20. L2K2

    L2K2

    Viestejä:
    758
    Rekisteröitynyt:
    17.10.2016
    Tiiviste, ei salaus! Tämä on oleellinen ero. Salaus = avattavissa oleva muunnos, tiiviste = lähtökohtaisesti yksisuuntainen.

    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.

    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.

    Vaihtamiseen pakottamisesta ei ole myös mitään järkeä. Se johtaa tutkitusti heikompien salasanojen käyttöön.

    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).
     
  21. Vauhtimursu

    Vauhtimursu

    Viestejä:
    292
    Rekisteröitynyt:
    30.07.2017
    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.

    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 ?
     
    Viimeksi muokattu: 28.04.2019
  22. Rensu

    Rensu

    Viestejä:
    292
    Rekisteröitynyt:
    17.10.2016
    Windows käyttää ainakin Bitlockerin kohdalla PIN-koodi nimitystä, mikä on mielestäni järjettömyyden huippu.
     
  23. Vauhtimursu

    Vauhtimursu

    Viestejä:
    292
    Rekisteröitynyt:
    30.07.2017
    Jep.

    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...
     
  24. Algron28

    Algron28

    Viestejä:
    1 332
    Rekisteröitynyt:
    17.10.2016
    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ä.
     
    akir0 ja Leo_Greta tykkäävät tästä.
  25. oselotti

    oselotti

    Viestejä:
    331
    Rekisteröitynyt:
    02.11.2016
    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
     
    Markok tykkää tästä.
  26. kaakau<"'\\/>

    kaakau<"'\\/>

    Viestejä:
    403
    Rekisteröitynyt:
    02.11.2016
    Tässä on huonona puolena, että käyttäjiä voi tavallaan dossata helposti, niin ettei pääse kirjautumaan palveluun pitkään aikaan.
     
  27. Vauhtimursu

    Vauhtimursu

    Viestejä:
    292
    Rekisteröitynyt:
    30.07.2017
    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..
     
  28. Stanley H. Tweedle

    Stanley H. Tweedle

    Viestejä:
    2 257
    Rekisteröitynyt:
    18.10.2016
    Tässä on aika hyvä artikkeli aiheesta ja sivustolla on työkalu jolla testata salasanoja:
    Secure Salted Password Hashing - How to do it Properly

    Testailin huvikseni taannoin yhdestä tietokannasta käyttäjien salasanoja ja todella helposti murtuivat yleiset/simppelit tapaukset.
     
    oselotti tykkää tästä.
  29. L2K2

    L2K2

    Viestejä:
    758
    Rekisteröitynyt:
    17.10.2016
    Odotinkin jotain tällaista vastausta..

    Kerro tämä toki myös esim. maailman suurimman verkkosisältömoottorin kehitystiimille ;-) Function Reference/wp hash password « WordPress Codex

    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?)
     
  30. oselotti

    oselotti

    Viestejä:
    331
    Rekisteröitynyt:
    02.11.2016
    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.

    Surullisenkuuluisia MD5-tapauksia löytyy, kuten esim. Ashley Madisonin tapaus:
    Once seen as bulletproof, 11 million+ Ashley Madison passwords already cracked



    Linkitin tämän tutkimuksen taannoin tietoturvaketjuun, mutta laitetaan se myös tähän, kun liittyy hyvin aiheeseen.
    https://net.cs.uni-bonn.de/fileadmin/user_upload/naiakshi/Naiakshina_Password_Study.pdf

    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.
     
  31. L2K2

    L2K2

    Viestejä:
    758
    Rekisteröitynyt:
    17.10.2016
    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...
     
  32. oselotti

    oselotti

    Viestejä:
    331
    Rekisteröitynyt:
    02.11.2016
    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.

    Tarkoitatko esimerkiksi tällaista:
    Koodi:
    suola . MD5(salasana . suola) . bcrypt(salasana . suola)
    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ä.

    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).

    EDIT: Kolmanneksi vielä se, että tuo tiivisteiden konkatenaatio ei edes toimisi, koska bcrypt tuottaa joka kerralla erilaisen tiivisteen juurikin algoritmin sisäisen suolaamisen takia.

    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
     
    Viimeksi muokattu: 30.04.2019
  33. L2K2

    L2K2

    Viestejä:
    758
    Rekisteröitynyt:
    17.10.2016
    Mutta toki silti esim. se linkittämäsi tutkimus piti sitä sellaisena.. siis kelvollinen.

    Ei ole pakko, mutta tuo sekunti (tai vaikka neljännessekunti) ei ollut omaa keksintöäni. Tuo oli lainaus ns. muualta.

    Esimerkki jälkimmäisestä, ”perusteltuna numeroilla”: Recommended # of iterations when using PKBDF2-SHA256?

    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.

    Hups. o-O

    Joo, ei pitäisi ehdottaa foorumipostauksessa uusia menetelmiä. Tuo oli oppikirjaesimerkki kryptografisesta ”TAI” operaatiosta. Tämä selittänee miksi moista ei ole.

    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ä.

    Tämä! Toistan vain tuon ”hups”.

    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
     
  34. oselotti

    oselotti

    Viestejä:
    331
    Rekisteröitynyt:
    02.11.2016
    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
     
  35. L2K2

    L2K2

    Viestejä:
    758
    Rekisteröitynyt:
    17.10.2016
    Ä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.

    [ Vain rekisteröityneet käyttäjät näkevät Spoiler-tagin sisällön. Rekisteröidy foorumille... ]

    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:

    Esimerkki (huonosta) dokumentaatiosivusta: bcrypt

    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"))”.

    [ Vain rekisteröityneet käyttäjät näkevät Spoiler-tagin sisällön. Rekisteröidy foorumille... ]

    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.

    Voit myös varmistua lähdekoodeista: pyca/bcrypt

    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).
     
  36. oselotti

    oselotti

    Viestejä:
    331
    Rekisteröitynyt:
    02.11.2016
    No nythän itsekin toteat, ettei paperista voida vetää johtopäätöstä siihen, että MD5 olisi turvallinen algoritmi. Olemme siis samaa mieltä.

    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.

    Kun suola kerran on täysin uniikki ja satunnaisesti generoitu, voi kirjasto sen luomisen hoitaa automaattisesti, kuten useimmat kirjastot tekevät. Tottakai joku voi tehdä kirjaston, joka ottaa suolan käyttäjältä, mutta ei se johda siihen, etteikö kirjasto voisi sitä tehdä automaattisesti.

    Tietysti sen suolan pitää löytyä sitä tiivisteestä, eihän sitä tiivistettä pystyisi varmentamaan muuten. Kts. esimerkki:

    Koodi:
    const bcrypt = require('bcrypt')
    const argon2 = require('argon2')
    const salasana = 'salasana'
    
    ;(async () => {
      const bcrypt1 = await bcrypt.hash(salasana, 10)
      const bcrypt2 = await bcrypt.hash(salasana, 10)
      console.log(`bcrypt hashit:\n${bcrypt1}\n${bcrypt2}`)
    
      const argon21 = await argon2.hash(salasana)
      const argon22 = await argon2.hash(salasana)
      console.log(`argon2 hashit:\n${argon21}\n${argon22}`)
    })()
    Joka tulostaa:
    Koodi:
    $ node index.js
    bcrypt hashit:
    $2b$10$Qq5/.U5H1EtmHxwjTJxOleiIU/ioD49RNnyrhpq0tRgeW9815WB0m
    $2b$10$5iWxirD2Mute/KtVGv.nwedKEDDYCHBG2dfemdhYeN5AZ1w/0zbSS
    argon2 hashit:
    $argon2i$v=19$m=4096,t=3,p=1$KZNnleDYuKPw8E1oF/+6zw$liesC49bU/fK+8c46O7h4rrCZ1lPv/S7Kmmo/03DUuM
    $argon2i$v=19$m=4096,t=3,p=1$OVc3cCNNI1+8IDwlNj6LZw$KQhlCrWo5TIgY+CdFvUheepXXny1bQ2Ze8c5JaWJ2ng
    Onko tämä nyt sitä taikuutta, että suola ilmestyy tiivisteeseen automaattisesti? Jos luodaan peräjälkeen kaksi tiivistettä samasta salasanasta, ovat ne silti täysin erilaisia, sillä kummallakin on uniikki suola.

    Sama salasana ei tietenkään saa samaa suolaa, silloin suola ei olisi uniikki. Salasanakohtaisuudella ei tarkoitettu tässä sitä, että samalle salasanalle aina laskettaisiin sama suola, vaan sitä, että jokaisella salasanatiivisteellä on uniikki suola. Toisin sanoen sama salasana generoi erilaisen tiivisteen jokaisella kerralla, kuten yllä olevasta esimerkistä paljastui.
     
  37. L2K2

    L2K2

    Viestejä:
    758
    Rekisteröitynyt:
    17.10.2016
    Annatko vielä perustelun tälle väitteelle?

    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)”.
     
    Viimeksi muokattu: 01.05.2019
  38. oselotti

    oselotti

    Viestejä:
    331
    Rekisteröitynyt:
    02.11.2016
    Suola ei saa olla ennalta arvattavissa eikä sitä saa käyttää moneen kertaan, sillä muutoin hyökkääjä voi laskea rainbow tablen sen avulla, toisin sanoen hän voi hyökätä monen kohteen kimpuun yhdellä työllä. Täten suolan on aina oltava täysin satunnainen ja kyllin pitkä ollakseen uniikki.

    No vaikka siinä paperissa lukisi suoraan, että "MD5 on turvallinen algoritmi salasanojen suojaamiseen", niin ei se siitä algoritmista oikeasti turvallista tekisi. Linkitin paperin sen takia, että halusin näyttää, että MD5-algoritmin luuleminen hyväksi on aika yleistä.

    Mielestäni olen vastannut kaikkiin pointteihin. Keskustelu kiertää kehää, oliko siellä joku tietty epäselvä asia?

    Niin, se johtuu siitä, että bcrypt on suunniteltu nimenomaisesti salasanoja varten, kun taas MD5 on yleiskäyttöinen. Bcrypt sisältää muutakin, kuin pelkän suolan. Esimerkiksi salasanan vertaileminen tiivisteeseen tehdään siten, ettei ajastushyökkäykset onnistu, kun taas MD5-algoritmia käytettäessä sekin on implementoitava itse, mitä ei monikaan tiedä taikka tee.
    Timing attack - Wikipedia

    Esim. jos otetaan Python esimerkiksi:
    Koodi:
    # Tiivisteitä ei saa koskaan vertailla näin
    def naiivi_vertailu(hash_1, hash_2):
        if hash_1 == hash_2:
            return True
        return False
    
    # Tämä saattaa EHKÄ olla turvallinen tapa, mutta ei välttämättä ole
    def vertailu(hash_1, hash_2):
        if len(hash_1) != len(hash_2):
            return False
        diff = 0
        for x, y in zip(hash_1, hash_2):
            diff |= ord(x) ^ ord(y)
        return diff == 0
    
    Jos tiivisteiden vertailu ei tapahdu vakioajassa, niin hyökkääjä voi käyttää vertailuun tapahtuvaa aikaa hyväksi ja saada siitä tietoa, joka ei hänelle kuulu.

    Nyt kun tällaista MD5-disinformaatiota levitetään foorumeilla, niin ei oteta huomioon mitään tällaisia juttuja. Salasanojen suojaamiseen tarkoitetut kirjastot hoitavat nämä asiat automaattisesti oikein.



    Katsoin muuten WordPressin lähdekoodista tuon MD5-tapauksen. He käyttävät sitä sen takia, että se on ainoa kaikkien tällä hetkellä käytössä olevien PHP-versioiden tukema algoritmi (kommentti lähdekoodissa), ei sen takia, että se olisi jotenkin hyvä algoritmi.
    WordPress/WordPress

    [ Vain rekisteröityneet käyttäjät näkevät Spoiler-tagin sisällön. Rekisteröidy foorumille... ]
     
  39. Obi-Lan

    Obi-Lan ¯\_(ツ)_/¯

    Viestejä:
    617
    Rekisteröitynyt:
    17.10.2016
    Tai sitten voisi ottaa käyttäjän autentikoinnin Oauthilla Google/Facebook/MS ? Olisi yksi passu vähemmän muistettavana.
     
  40. joku43

    joku43

    Viestejä:
    156
    Rekisteröitynyt:
    03.02.2017
    :rofl: CMS sontaläjä ja maailman paskin ohjelmointikieli ne yhteen sopii, ja tietoturva on MD5 tasoa :rofl:
     
  41. Vauhtimursu

    Vauhtimursu

    Viestejä:
    292
    Rekisteröitynyt:
    30.07.2017
    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 ?
     
    Viimeksi muokattu: 11.05.2019