Keskustelua salasanoista

[Grazer]

Aloitetaanpa tällainen ketju, kun tuli tuossa päivänä eräänä yksi asia mieleen. Meillä, kuten varmaan monella muullakin, on varsinkin työpuolella erinäisissä portaaleissa pakotettu salasanan vaihto x kuukauden välein ja järjestelmässä saattaa olla tarkastus, ettei uusi salasana ole liian samankaltainen vanhentuneen salasanan kanssa.

Tästäpä tulikin sitten mieleen kysymys, että kun missään asiallisesti tehdyssä palvelussa salasanat eivät saa olla selkokielisesti tallessa, mistä esim. Windows (vai Domain Controller) voi tietää vanhan salasanani selkokielisenä, jotta se pystyy sitä vertaamaan uuteen? Tehdäänkö tuo vertailu jotenkin lennossa client-päässä kun salasanaa vaihdetaan? Osaako joku selittää tämän pätevästi?

EDIT: Tai entä tilanne, jossa seurataan myös esim. ettei uusi salasana muistuta viittä edellistä salasanaa liiaksi? Pitäähän nuokin jossain säilöä?

 

[mikajh]

Siis siellähän voi olla N kpl vanhojen salasanojen salted hasheja tallessa, jolloin saman salasanan uudelleenkäyttö estetään tiettyyn rajaan saakka.
Tuollaista selväkielisen salasanan vertailua edelliseen ei missään turvallisessa järjestelmässä voi olla.
Ja uuden salasanan kompleksisuustarkistus on taas tietysti vielä eri asia

 

[topiv]

Salasanoista tallennetaan tiiviste, joka tuotetaan laskennallisesti alkuperäisestä salasanasta. Tiivistettä verrataan kirjautumisessa syötettyn salasanan tiivisteeseen. Lisäksi tiiviste voidaan suolata, joka tekee siitä satunnaisemman.

Asiaa on selitetty esimerkiksi täällä:

MASO | Salasanojen tallennuksen tekniikka

 

[ravallo]

Ihmettelin tuota joskus itsekin, samankaltainen != samanlainen, eli vaikka siellä olis vanhat hashit tallessa niin niiden kautta ei voi hakea kuin täsmällistä matchia, ja kuitenkin jotkut järjestelmät väittävät ettei uusi salasana saa muistuttaa liikaa mitään 5 vanhasta salasanasta.

En äkkiä keksinyt tuohon mitään muuta tapaa kuin se, että kun vaihdossa pitää aina syöttää se vanha salasana ja uusi salasana, niin uudesta tallennetaan vain hash mutta vanha tallennetaan sellaisenaan. En tiedä onko näin, mutta tuollainen vanhojen salasanojen kanta tuntuisi täysin horror turvallisuusriskiltä...

Hmm, paitsi että voisihan tuon tehdä niin, että sen vanhan salasanan tallentaa symmetrisellä salauksella sillä uudella salasanalla, ja sitten salasanan vaihdossa purkaa sen sillä annetulla vanhalla (nykyisellä) salasanalla ja salaa sen aiemman, ja sen nyt vaihdettavan taas sillä uudella, ja niin edelleen, jolloin olisi mahdollista ylläpitää salattua kantaa vanhoista salasanoista ja silti tarkastaa ne aina salasanan vaihdon yhteydessä...

 

[MrB]

Jos arvata pitäis, niin se liian samankaltaisten salasanojen käytön blokkaaminen vaatis ton viimeisen asetuksen enabloinnin. (kuva jonkun satunnaisen ympäristön AD-pannulta mulkastu GPO)

 

[FrontSchwein]

Yksi arvaus olisi että wanhat salasanat käsitellään jollain erikoisemmalla funktiolla ja tallennetaan johonkin. Erikoisempi funktio siksi että tavanomaiset tiivistefunktiot tai symmetrisen salauksen funktiot eivät kelpaa. Nimittäin tiivistefktioissa 1 bitin muutos inputissa pitäisi muuttaa mahdollisimman monta bittiä outputissa ja samaan tapaan symmetrisessä salauksessa on toivottavaa jotta kaikki outputin bitit riippuvat kaikista inputin ja avaimen biteistä.

... tiedä sitten olisiko kuitenkin jollain tavalla sovellettu symmetrisen salauksen fktioita. Niissähän se kryptaus jakautuu aloitus- , lopetus- ja välivaiheisiin. Niin jos välivaiheita vähemmän kuin oikeassa kryptauksessa niin vastaavasti vähäiset muutokset inputissa johtaisivat vähäisiin muutoksiin outputissa.
Joku Bruce Schneier tai Scheier taisi aikoinaan kirjoittaa sellaisen kirjan mikä näitä kryptoasioita käsitteli, katsokaa siitä.

 

[mikajh]

Kaikkein paras salasanojen turvallisuutta koskeva ohje on: älä käytä yhtäkään salasanaa enää ikinä
(en. passwordless)

 

[ravallo]

Yksi arvaus olisi että wanhat salasanat käsitellään jollain erikoisemmalla funktiolla ja tallennetaan johonkin. Erikoisempi funktio siksi että tavanomaiset tiivistefunktiot tai symmetrisen salauksen funktiot eivät kelpaa. Nimittäin tiivistefktioissa 1 bitin muutos inputissa pitäisi muuttaa mahdollisimman monta bittiä outputissa ja samaan tapaan symmetrisessä salauksessa on toivottavaa jotta kaikki outputin bitit riippuvat kaikista inputin ja avaimen biteistä.

... tiedä sitten olisiko kuitenkin jollain tavalla sovellettu symmetrisen salauksen fktioita. Niissähän se kryptaus jakautuu aloitus- , lopetus- ja välivaiheisiin. Niin jos välivaiheita vähemmän kuin oikeassa kryptauksessa niin vastaavasti vähäiset muutokset inputissa johtaisivat vähäisiin muutoksiin outputissa.
Joku Bruce Schneier tai Scheier taisi aikoinaan kirjoittaa sellaisen kirjan mikä näitä kryptoasioita käsitteli, katsokaa siitä.

Eihän tuossa tarvitse mitään salattuja arvoja vertailla, kun sulla on kuitenkin aina salasanan vaihdon yhteydessä sekä nykyinen että tuleva salasana. Eli näin:

Luo käyttäjä:
    Käyttäjänimi: masa69
    Salasana: tammikuu69 --> hash 6f3e8e02a7c938598ba2455caea5fb1c8f1d7f5449dfb4e5e6b929958ae94b94

Vaihto 1:
    Vanhasalasana: tammikuu69 --> verrataan hash 6f3e8e02a7c938598ba2455caea5fb1c8f1d7f5449dfb4e5e6b929958ae94b94 --> ok
    Uusisalasana: helmikuu69 --> Verrataan Uusisalasana vs. Vanhasalasana --> riippuen säännöistä ok
    Salataan Uusisalasanalla symmetrisesti tauluun VANHAT masa69 : tammikuu69
    Tallennetaan Uusisalasana --> hash 4b530e96f9e7f504163369c08e97b78458e383805fe7896dc2a519f95f4673cc

Vaihto 2:
    Vanhasalasana: helmikuu69 --> verrataan hash 4b530e96f9e7f504163369c08e97b78458e383805fe7896dc2a519f9 --> ok
    Haetaan taulusta VANHAT ja avataan Vanhasalasana: lla masa69 : tammikuu69
    Uusisalasana: maaliskuu69 --> Verrataan Uusisalasana vs. Vanhasalasana ja VANHAT (helmikuu69 ja tammikuu69) --> riippuen säännöistä ok
    Poistetaan taulusta VANHAT masa69 -rivit
    Salataan Uusisalasanalla symmetrisesti tauluun VANHAT masa69 : tammikuu69, helmikuu69
    Tallennetaan Uusisalasana --> hash 2dbe9a37348abc51548f5b96cfdda135c4e0be3953588d59a9c33da14aea0c7a

Vaihto 3:
    Vanhasalasana: maaliskuu69 -->  verrataan hash 2dbe9a37348abc51548f5b96cfdda135c4e0be3953588d59a9c33da14aea0c7a
    Haetaan taulusta VANHAT ja avataan Vanhasalasana: lla masa69 : tammikuu69, helmikuu69
    Uusisalasana: huhtikuu69 --> Verrataan Uusisalasana vs. Vanhasalasana ja VANHAT (helmikuu69, tammikuu69 ja maaliskuu69) --> riippuen säännöistä ok
    Poistetaan taulusta VANHAT masa69 -rivit
    Salataan Uusisalasanalla symmetrisesti tauluun VANHAT masa69 : tammikuu69, helmikuu69, maaliskuu69
    Tallennetaan Uusisalasana --> hash 191217026c166c193bdee9b56cdfcc6188675d41d654612a0180bc205aa5b308

...ja niin edelleen. Tuossa on se heikko puoli että käyttäjän n vanhaa salasanaa on mahdollisesti heikon salasanan takana symmetrisesti salattuna, mutta kuitenkin niin että yhdellä salasanalla ei aukea koko historia kaikilta käyttäjiltä.

 

[escalibur]

Kaikkein paras salasanojen turvallisuutta koskeva ohje on: älä käytä yhtäkään salasanaa enää ikinä
(en. passwordless)

Harmi vain kuin suurin osa järjestelmistä ei tue koko ominaisuutta. Sen lisäksi passwordless-tunnistautumisen hallitseminen useamman tunnuksen, tai palvelun kohdalla voi olla haastavaa jos mobiililaite hajoaa tai katoaa yllättäen. Passwordlessissa on varmasti potentiaalia ja siihen ollaan luultavasti menossakin, mutta maailma ei vain vielä ole valmis siihen.

Itse lopettaisin tarpeettomat salasanavaihdot, ne kun eivät vaikuta tietoturvaan oikein mitenkään.

The Guy Who Invented Those Annoying Password Rules Now Regrets Wasting Your Time

We’ve all been forced to do it: create a password with at least so many characters, so many numbers, so many special characters, and maybe an uppercase

gizmodo.com

ps. Signun linkin takaa löytyy muutama video liittyen salasanoihin, teille joita aihe saattaisi kiinnostaa.

 

[FrontSchwein]

Eihän tuossa tarvitse mitään salattuja arvoja vertailla, kun sulla on kuitenkin aina salasanan vaihdon yhteydessä sekä nykyinen että tuleva salasana. Eli näin:

Luo käyttäjä:
    Käyttäjänimi: masa69
    Salasana: tammikuu69 --> hash 6f3e8e02a7c938598ba2455caea5fb1c8f1d7f5449dfb4e5e6b929958ae94b94

Tuossa aiemmassa mulla oli pointtina "ettei uusi salasana ole liian samankaltainen vanhentuneen salasanan kanssa " , kuitenkin niin ettei tarvitsisi plaintext:inä tallentaa vanhoja salakaloja.
Suhtauduin epäillen siihen että moiseen tavoitteeseen päästäisiin näillä tavanomaisilla tiiviste- tai symmetrinen_salaus-fktioilla. Johtuen juurikin näistä ominaisuuksista mitä em-. fktioilla Schneierin mukaan tulisi olla). Näin muistan lukeneeni joskus.

Kyllähän sellaisillekin fktioille luulisi löytyvän käyttöä, joilla a)pieni muutos inputissa johtaa pieniin muutoksiin outputissa ja b) mielivaltaisen pitkä syöte tiivistyy max. kouralliseen 64 bitin sanoja.

Tuo sinun "vanha salasana->uusi salasana"-systeemisi on taas vähän eri juttu kuin mitä meinasin. Rohkenen epäillä että sinun menetelmälläsi pystyy havaitsemaan vain tapauksen missä uusi salasana on täsmälleen jokin wanhoista salasanoista. Jos siinä nyt ylipäänsä on tarkoitus tuommoista tilannetta havaita siis.

Toisaalta tuossa "inputit lähellä"->"outputit lähellä"-systeemissäkin on se juttu että miten siinä saa ne salasanat pysymään salassa. Jollain tavalla pitäisi saada jokin avain mukaan ettei olisi liian helppoa arvata.

Edit. joskohan nyt menisi tagit oikein ja muutenkin tarpeeksi täsmällisesti sanottu.

 

[ravallo]

Tuossa mun systeemissähän päästään vertaamaan plaintext vs plaintext -salasanoja ilman että mitään kuitenkaan tallennetaan tai siirretään plaintextina. Niille vois ajaa ihan niin monimutkaisen permutaatiovertailun kuin kehtaa javascriptinä asiakaspäässä pyörittää. En siis tiedä onko nuo oikeasti toteutettu noin, mutta ihan teoreettisena neppailuna, noin sen voisi tehdä.

Typerä systeemihän tuo on, ylipäänsä jos kerran on pakko käyttää salasanoja, niin mieluummin rohkaisisi ihmisiä käyttämään vahvoja ja uniikkeja salasanoja sen sijaan että pakottaa jengiä vaihtelemaan niitä. Ilman pwd manageria tuollainen ohjaa juurikin heikkojen salasanojen käyttöön, esimerkiksi tuollaisella mun esimerkissä käyttämällä kuukausi -prefix/postfix -systeemillä, joka on aika altis sanayhdistelmähyökkäyksille.

 

[FrontSchwein]

Tuossa mun systeemissähän päästään vertaamaan plaintext vs plaintext -salasanoja ilman että mitään kuitenkaan tallennetaan tai siirretään plaintextina. Niille vois ajaa ihan niin monimutkaisen permutaatiovertailun kuin kehtaa javascriptinä asiakaspäässä pyörittää. En siis tiedä onko nuo oikeasti toteutettu noin, mutta ihan teoreettisena neppailuna, noin sen voisi tehdä.

Typerä systeemihän tuo on, ylipäänsä jos kerran on pakko käyttää salasanoja, niin mieluummin rohkaisisi ihmisiä käyttämään vahvoja ja uniikkeja salasanoja sen sijaan että pakottaa jengiä vaihtelemaan niitä. Ilman pwd manageria tuollainen ohjaa juurikin heikkojen salasanojen käyttöön, esimerkiksi tuollaisella mun esimerkissä käyttämällä kuukausi -prefix/postfix -systeemillä, joka on aika altis sanayhdistelmähyökkäyksille.

Siis niin että jokaista käyttäjä+salasana-kombinaatiota kohti on oma rivinsä jossain taulussa? Vai niinpäin että jokaista käyttäjää kohti on 1 rivi jossa kenttänä kaikki aiemmat salasanat pötkönä?
Jälkimmäisestä tulee mieleen a) xor b) Diffie-Hellman c) determinantit. Että jos jotain niitä pystyisi jollain lailla hyödyntämään. Asia erikseen onko silloin mitään oikeaa tietoturvaa läsnä.

Esmes (g**a)*(g**b)=g**(a+b) ja jos a=b niin silloin tulos onpi g**(2a)
tai f(a xor b)=f(0) kun a=b


Sittenhän sitä on kanssa PBKDF2 ja argon ja mitä olikaan, sitä varten että hankaloitetaan salasanojen murtamista.

 

[ravallo]

Ei kai sillä sinänsä ole väliä onko ne taulussa samalla vai eri rivillä, joka tapauksessa ne vanhat passut pitää olla kaikki aina salattuna sillä uusimmalla salasanalla, jollain sopivalla algoritmillä, AES256 tms.

 

[FrontSchwein]

Ehkä jotain saisi tosiaan aikaiseksi idealla: AES256(x xor (x xor e),k)=AES256(e,k) . Niinqu saisi joitain vaihtoehtoja suljettua pois.Se "uusi pw ei liian lähellä wanhaa"-idea siis.

Tai jos ihan väen väkisin haluaa mussuttaa niin siitä että joutuisi symmetrisen salausfktion kanssa dekryptaamaan ne aiemmat passut tai sen pötkön missä kaikki aiemmat passut xor:attuna yhteen tjsp niin siinähän olisi sitten tietsikan muistissa jonkin aikaa ne salasanat selkokielisenä.

 

[FrontSchwein]

Tai raskaaksihan se käy pidemmän päälle kun joka salasanan kohdalla tulee jokin määrä lisää kiellettyjä variaatioita. Ettei olisi uusi liian lähellä wanhaa.

 

[ravallo]

Sulla on tuossa salasanan vaihtovaiheessa joka tapauksessa työmuistissa salasanat selkokielisenä, ja vieläpä se aktiivinen salasana, jos se korkkaa niin tuskinpa niillä vanhoillakaan on juuri merkitystä.

 

[edup]

Ainakin yksi tapa toteuttaa tuo on se, että vanhoista salasanoista on tiivisteet säilöttynä. Kun sitten valitset uutta salasanaa, se on luonnollisesti selkokielisenä. Kone sitten automaattisesti kokeilee tietyt muokkaukset ja laskee muokatuille uusille salasanoille tiivisteet joita vertaillaan vanhoihin. Eli jos vaikka salasana pitää erota yli yhdellä merkillä aiemmista, niin silloin uuteen salasanaan kokeiltaisiin korvata jokainen merkki millä tahansa muulla merkillä, ja sitten vain vertaillaan tiivisteitä. Tässä voi tietenkin olla myös merkkien poistoja ja lisäyksiä mukana.

Samankaltaisuuskielto ei saa olla liian tiukka, sillä muutoin tuossa joudutaan kokeilemaan ihan järjetön määrä komboja. Tosin nopeasti siinä käyttäjältäkin palaisi käpy jos mikään uusi salasana ei kelpaa kun sen pitää erota vanhoista yli 8 merkin osalta tms. Mutta hashien laskenta ja vertailu on nopeaa, joten pienemmille muokkausetäisyyksille tuo on ihan tehtävissä. Ja todellisuudessa nuo samankaltaisuusestot on aika heikkoja, eli testataan ihan lähinnä 1-2 merkin tarkkuudella samankaltaisuutta. Siihen lisäksi se, että salasanojen sallitut merkit on usein rajattu melko suppeaan joukkoon, jolloin niitä korvauksiakaan ei tarvitse testata ihan ääretöntä määrää.

 

[ravallo]

Ainakin yksi tapa toteuttaa tuo on se, että vanhoista salasanoista on tiivisteet säilöttynä. Kun sitten valitset uutta salasanaa, se on luonnollisesti selkokielisenä. Kone sitten automaattisesti kokeilee tietyt muokkaukset ja laskee muokatuille uusille salasanoille

Melkeinpä veikkaisin että tuo on se tapa millä juttu on oikeasti toteutettu noissa "riittävän erilainen kuin n edellistä" -skeemoissa. Monta hyvää puolta, ei tarvitse säilöä missään muodossa, edes kryptattuna, niitä salasanoja, ja toisaalta tuo on myös se tekniikka millä salasanaa oikeasti yritettäisiin murtaa. Nopeilla hasheilla saa nykäistyä aika monta muunnosta ihan lennosta.

 

[FrontSchwein]

Tekisi mieli inttää että ehkä Diffie-Hellmania tai ElGamalia hyödyntämällä voisi muodostaa salasanan variaation tiivisteet (tai "tiivisteet") ilman että varsinaista salasanaa tarvitsisi plaintext:inä tietää. Mulla on tylsää.

 

[Grazer]

Mielenkiintoinen tuo salasananvaihto domainiin liitetyssä Windows 10:ssä. Nyt aamulla tuli salasana vanhentunut jonka päivitin uuteen. Tuon vaihdon jälkeen alkaa Teamsit, Outlookit, Office ym. huutaa salasanan syöttämistä, mutta noille ei kelpaa uusi salasana, vaan kun syöttää vanhan salasanan, niin ovat tyytyväisiä. Miksi ne kysyvät vanhaa salasanaa, se on niillä tiedossa jo?

On kyllä hyvät säännöt meilläkin, kun salasanaan kelpasi laittaa sanat "helppo" ja "salasana". Toinen noista isolla. Tuon lisäksi sitten jotain numeroa ja erikoismerkkiä.

 

[pulatunnus]

Eihän tuossa tarvitse mitään salattuja arvoja vertailla, kun sulla on kuitenkin aina salasanan vaihdon yhteydessä sekä nykyinen että tuleva salasana. Eli näin:

Kuten mainitsit niin tuo toimii vain salasanoihin joiden salasana tiedetään.
Ehkä vähän riskaapelia tallentaa vanhoja salasanoja, jos ja kun ei voida luottaa siihen että ne olisi täysin yksilöllisiä, ainutkertaisia.

Jos ei kovin kummoista keinoälyvertailua tarvita, vaan riittää että verrataan ettei käytetä samaa runkoa (pätkää), niin voisko vain vertailla tiivisteitä pätkistä ?

Vuotaa tuokin, mutta olisko vähän vähemmän vuotava.

Kaikkein paras salasanojen turvallisuutta koskeva ohje on: älä käytä yhtäkään salasanaa enää ikinä
(en. passwordless)

Jaa että mielummin ovi auki.

Parempi pitää umpisureka salasana (lukko), kuin ei mitään, varsinkin julkissa paikoissa (netti) on hyvin oleellinen ero onko salasana vai ei mitään. Siihen verrattuna on sitten kärjistäen hienosäätöä kuinka vahva salasana/tunnistus , toki jos suojaat jonkin muun tietoja/omaisuutta , niin sinne päin jutuilla ei vastuusta selviä.

Ja oiken salattavan tiedon osalta muistettava että jos postikortilla lähettää (julkisen netin yli) niin parempi olettaa että se salaus/suoja voidaan murtaa joskus, ja sen on joku tallentanut.

 

[FireExit]

Kuten mainitsit niin tuo toimii vain salasanoihin joiden salasana tiedetään.
Ehkä vähän riskaapelia tallentaa vanhoja salasanoja, jos ja kun ei voida luottaa siihen että ne olisi täysin yksilöllisiä, ainutkertaisia.

Jos ei kovin kummoista keinoälyvertailua tarvita, vaan riittää että verrataan ettei käytetä samaa runkoa (pätkää), niin voisko vain vertailla tiivisteitä pätkistä ?

Vuotaa tuokin, mutta olisko vähän vähemmän vuotava.



Jaa että mielummin ovi auki.

Parempi pitää umpisureka salasana (lukko), kuin ei mitään, varsinkin julkissa paikoissa (netti) on hyvin oleellinen ero onko salasana vai ei mitään. Siihen verrattuna on sitten kärjistäen hienosäätöä kuinka vahva salasana/tunnistus , toki jos suojaat jonkin muun tietoja/omaisuutta , niin sinne päin jutuilla ei vastuusta selviä.

Ja oiken salattavan tiedon osalta muistettava että jos postikortilla lähettää (julkisen netin yli) niin parempi olettaa että se salaus/suoja voidaan murtaa joskus, ja sen on joku tallentanut.

Passwordless: Paranna tietoturvaa salasanattomalla todentamisella – Microsoft Security

 

[Yeenoghu]

Mielenkiintoinen tuo salasananvaihto domainiin liitetyssä Windows 10:ssä. Nyt aamulla tuli salasana vanhentunut jonka päivitin uuteen. Tuon vaihdon jälkeen alkaa Teamsit, Outlookit, Office ym. huutaa salasanan syöttämistä, mutta noille ei kelpaa uusi salasana, vaan kun syöttää vanhan salasanan, niin ovat tyytyväisiä. Miksi ne kysyvät vanhaa salasanaa, se on niillä tiedossa jo?

On kyllä hyvät säännöt meilläkin, kun salasanaan kelpasi laittaa sanat "helppo" ja "salasana". Toinen noista isolla. Tuon lisäksi sitten jotain numeroa ja erikoismerkkiä.

Arvaan että joko SSO ei ole synkronoinut vielä salasanoja ympäriinsä, tai sitten domainissa on eri salasanan monimutkaisuussäännöt kuin O365:ssä. Eli salasanasi kelpaa domainiin, muttei O365:een -> salasanat epäsynkroonissa.

 

[FrontSchwein]

Jos ei kovin kummoista keinoälyvertailua tarvita, vaan riittää että verrataan ettei käytetä samaa runkoa (pätkää), niin voisko vain vertailla tiivisteitä pätkistä ?

sha256("kanankakka")=7ecbfa200f5bbfbbb4ae64081919425784e003c19c543076f1f5c6b2b371b568
sha256("kanankakkb")=0ad5075bdf3f92916f2b4080a296aa2fcb4675e3f161f8877aac5ebd47519426
sha256("kanankakk")=503597e9bc1e69fa43dbe237d4e7932cd815add97958795ad3c793f3288426d7

tämmöisen ominaisuuden takia olen sitä mieltä että Diffie-Hell/ElGamal/GoldWasser-Mical ensin(variaatioita varten) ja sitten vasta tiivistefktio. Jos niinqu pitäisi jotain salasanasysteemiä lähteä koodaamaan. Ja olettaen että ne aiempien salakalojen simppelimmät variaatiot pitää saada suljettua pois.