FIDO2, WebAuthn, Passwordless ja Passkeys

[ztec]

Tetasin tässä päivänä eräänä uusia FIDO2 tokeneita, sekä SoloKeyssiltä, että eWBM:ltä ja nuo parantavat kyllä käyttäjätunnusten hallintaa ja tietoturvaa merkittävästi. Kirjautuminen palveluihin helpottuu olennaisesti ja tietoturva paranee.

Jos suinkin mahdollista unohdan vanhentuneet tekniikat kuten SecurID, SMS auth ja TOTP kaikissa niissä palveluissa joissa nuo uudet paremmat tekniikat on käytössä.

Myös uusilla Yubico:n Yubikeyllä toimii tietenkin vastaavat tietoturva-ominaisuudet.

Miksi uusi lanka? Koska kuulemma tämä ei ollut uutisiin sopiva aihe, vaikka siellä oli jo lanka aiheesta.

Jos käytössä ei ole vielä FIDO2 turvallisuusavainta, niin suosittelen tutustumaan ja kokeilemaan. On sen verran käytettävyyttä parantava tekijä, nopeuttaa loginia merkittävästi jne.

SoloKeyssillä käytetään turvallisuusvaimen aktivointiin PIN-koodia, kun taas eWBM:llä käytetään sormenjälkeä.

Mielenkiintoisena havaintona lisättäköön, että ainakin Android puhelimissa FIDO2 toimii myös puhelimen oman TPM modulin kautta ja aktivointi voidaan suorittaa sormenjäljellä. Tämä ominaisuus on varmasti mennyt monelta käyttäjältä ohi.

Firefoxissa on myös mahdollista käyttää Softkeys ominaisuutta, jolloin rautapohjaista avainta ei tarvita, ja kaikki tarpeellinen hoituu ohjelmistopohjaisesti selaimessa. Jotkut on myös toivoneet, että käyttöjärjestelmä hoitaisi avainten hallinnan, mutta silloin HSM etu tietenkin menetetään kuten myös silloin kun avainhallinta on selaimessa.

Löytyykö kokemuksia, näkemyksiä, kommentteja tai kysymyksiä?

 

[olkitu]

FIDO2 on kyllä mielenkiintoinen ja käytössä on jo Microsoftin palvelussa. Kaikki palvelut eivät tue näitä tikkuja niin OTP vielä toistaiseksi käytössä. Muistaa tietysti hankkia kaksi tikkua, toinen varalle että jos toinen hajoaa tai häviää.

 

[ztec]

FIDO2 on kyllä mielenkiintoinen ja käytössä on jo Microsoftin palvelussa. Kaikki palvelut eivät tue näitä tikkuja niin OTP vielä toistaiseksi käytössä. Muistaa tietysti hankkia kaksi tikkua, toinen varalle että jos toinen hajoaa tai häviää.

Osa palveluista kuten Twitter ei anna rekisteröidä kuin yhden tikun. Mutta Googlella tuo erilaisten autentikointitapojen hallinta on kyllä hoidettu aivan esimerkillisesti.

 

[olkitu]

Osa palveluista kuten Twitter ei anna rekisteröidä kuin yhden tikun. Mutta Googlella tuo erilaisten autentikointitapojen hallinta on kyllä hoidettu aivan esimerkillisesti.

Juu ei ihan oo kaikkialla kunnossa. Sama juttu Amazon AWS missä voi vain yhden tikun laittaa. Googlella käytössä Advanced Security Program: Google Advanced Protection Program - joka pakottaa vähintään kaksi tikkua asettamaan tilille. Tällä toivottavasti tarpeeksi hyvää suojaa saa.

Mutta tikuilla on hintaa että ymmärtää ettei suurinosa hanki tälläisiä.

 

[suni]

Itellä on käytössä vanhempi Yubikey Neo, mietinnässä uudempaa tikkua. Mikäs olis kansan suosittelema tällä hetkellä?

 

[olkitu]

Vielä pärjää aika hyvin vanhemmalla 4 -sarjan NEO:lla ainakin, itsellä on niitä ja sitten yksi tuo 5-sarjainen mutta FIDO2-tuki on vieä aika rajallista niin ei ihan hirveä hinku päivittää uudempaan. Microsoftin palvelussa tuo FIDO2 on olemassa toki ja Windows kirjautuminenkin pitäiis sillä onnistua.

 

[ztec]

Tämä on mennyt ohi minulta kokonaan. Pystytkö avaamaan tätä? Miten se toimii ja miten sitä käytetään?

Asetukset:

security.webauth.webauthn_enable_softtoken;true
security.webauth.webauthn_enable_usbtoken;false

Niin sen jälkeen toimii ilman hardista. Testaa: webauthn.io tai webauthn.me.

 

[ztec]

Passkeys tuo nyt sitten pilvipalveluiden kautta hallittavat identiteetti-avaimet. Sinänsä aika loistavaa edistymistä. Vielä kun tuo yhdisttäisiin vahvaan tunnistautumiseen jne. Hienoa nähdä että etenee, vaikka en kyllä henkeäni pidättele, yleensä näissä tuppaa menemään vuosikausia, eikä sittenkään päästä yhteissopimukseen asioista.

Passkeys: How multi-device FIDO credentials can replace passwords

This week, the FIDO Alliance published a whitepaper on multi-device FIDO credentials or “passkeys”. Read how passkeys can replace passwords.

www.hanko.io

Foliohatut suuttuu koska huono idea monestakin syystä niiden mielestä, mutta täähän on taas yksi ikuisuuskysymys. Koska sittenhän avaimet ei enää ole vain HSM:ssä tallessa. Ikuinen käytettävyys ja kätevyys vastaan turvallisuus aihe.

OAuth lupasi jo paljon, mutta eipä sitä(kään) oikein kukaan halunnut käyttää. Vain muutama ultra puristi saitti implementoi sen, eikä oikein kukaan koskaan käyttänyt sitä. Niissäkin paikoissa missä on implementointi se usein haudattiin pois silmistä.

Arvauksia koska WebAuthn on sitten virallisesti käytettävissä Suomessa? Mä vaan pelkään että vastaukset on 5 - 10 vuotta, tai ei koskaan. Sekä tietty selkeä linkitys mm. eIDAS järjestelmään ja identiteettiin.

 

[ztec]

FIDO2 - Moni ei muuten tunnu tietävän että nää toimii myös SSH:n kanssa. Aivan mainio tapa rajata pääsyä turvallisemmin.

Sekä sitten on olemassa myös softa / hardis hybridejä, kuten IDmelon. Siinä avaimet on esim. puhelimessa, logitus käytöstä pilvessä ja sitten PC:ssä on bluetooth bridge, jolla aktivointi PC:lle suoritetaan.

Erityisen kätevä mm. tilanteissa joissa on turvallinen toimipiste jossa käytetään asioita ja siellä on jaetut tietokoneet. Mutta ei haluta silti hankkia erillisiä fyysisiä FIDO2 avaimia käyttäjille. Nyt riittää että niillä on puhelimessa APPi ja sitten jaetussa turvallisessa työskentelypisteessä on USB-dongle jonka kautta tunnistautuminen tapahtuu langattomasti.

Varsin mielenkiintoinen hybridi konsepti. Tuo Passkeys-konsepti nyt varmaan tulee tätä vähän vesittämään. Toisin kuten tuolla toisessa langassa, niin aina välillä on vaatimuksia sen suhteen kuka autentikoi, miten ja kenellä on avainhallinta jne. Niin jossain tilanteissa kaikki vaihtoehdot eivät ole käytettävissä vaikka olisikin kovin käteviä.

Kaksivaiheinen vahvistus | Two-/Multi-factor authentication

Google authenticator on käytössä parissa paikassa ja vierastan hieman tuon käyttöä kun pelottaa jos puhelin vaikka hajoaa niin miten nuo tiedot saa uuteen puhelimeen. Meneekö se nyt niin, että jokaiseen palveluun joka tuossa authenticatorissa on niin siihen on oma palautusavain joka pitäisi...

bbs.io-tech.fi

Edit, typo-fix

 

[Paapaa]

FIDO2 - Moni ei muuten tunnu tietävän että nää toimii myös SSH:n kanssa. Aivan mainio tapa rajata pääsyä turvallisemmin.

Hep! Täällä käytössä. Laitoin itse asiassa GitHubiin ed25519-sk-avaimen, jonka kanssa SSH-operaatio vaatii siis avaimen hipaisun. Lopulta ei kovin paha hidaste ja suojaa osaltaan "push -f"-vahingoilta

Ja netissä pyörii vielä turhan paljon jotain ihme GPG-virityksiä SSH:lle. Niitä joutuu käyttämään, jos on liian vanha OpenSSH (< 8.2) asennettuna. Uudet versiot tukevat suoraan U2F/FIDO-protokollaa avaimille.

 

[ztec]

Passkeys on tulossa kovaa vauhtia, nyt kun Microsoft, Apple ja Google ajavat asiaa. Toivottavasti saadaan myös monialustaratkaisut toimimaan. Mikään ei ole tylsempää kuin se, että voit kirjautua palveluihin vain tietyllä tuoteperheellä, koska kaikki on lukittu niin, ettei toimi muiden palveluntarjoajien tuotteissa. Huoli on ilmaistu, mutta ainakaan vielä ratkaisuja ei ole ollut tarjolla.

Toisalta, tuo hieman sotii alkuperäistä FIDO2 ajatusta vastaan, jossa nimenomaisesti tarkoituksena oli, ettei privaatti avaimia koskaan käpisteltäisi. Tietysti viimeinen vaihtoehto on se, missä privaatti avaimet on aina jossain HSMssä tallessa, mutta itseasassa jaetaan niihin vain käyttöoikeuksia. Tietystii tuo tarkoittaa sitä, että HSM:n pitää olla yhteydet ja pääsynvalvonta kunnossa.

Päästään takaisin klassiseen ongelmaan, jossa halutaan huipputurvallinen ratkaisu, joka toimii niin ettet edes huomaa sen olemassaoloa. Itse kyllä suorastaan rakastan Passwordless kirjautumista, koska se ei vaadi mitään muuta kuin napin painamisen ja se on siinä. Äärimmäisen kiva, sujuva ja mukava tapa kirjautua verkkopalveluihin ja verrattain turvallinen, juuri siksi, että avaimet on lukittu avaimeen.

 

[Infy]

Tuossa tulee käsittääkseni välttämättä riippuvaiseksi paveluntarjoajasta, valitse Google, Microsoft tai Apple.

 

[Humanoid]

Tuossa tulee käsittääkseni välttämättä riippuvaiseksi paveluntarjoajasta, valitse Google, Microsoft tai Apple.

Tällä hetkellä joo, mutta salasanamanageihinkin tuo tuki on tulemassa. WebAuthnia tukee jo ainakin Dashlane, ja KeePassXC:llekin on olemassa jo kehitysbranch jossa tuo toimii. Passkeys käyttää tuota teknologiaa, joten en ihmettele, jos käyttö laajenee myös siihen.

Ihan loogista, että isot tahot pistävät kyllä WebAuthn/Passkeysin osalta vauhtia, mutta haluavat rajoittaa sen käytön vain omiin palveluihin. Ainaki esim. KeePassXC:n osalta taas aivaimet ovat vapaasti vietävissä ja tuotavissa myös muihin managereihin.

 

[user9999]

Ei noita passkeysiä hyödyntäviä sivustoja ole vielä paljon.

Passkeys.directory

A community-driven index of websites, apps, and services that offer signing in with passkeys.

passkeys.directory

PayPal passkeys will start rolling out today to customers in the U.S.. PayPal passkeys will become available in additional countries early in 2023, and on additional technology platforms as they add support for passkeys.

PayPal Introduces More Secure Payments with Passkeys

Passkeys are designed to replace passwords and allow seamless logins for consumers across devices and platforms. Makes online purchases easier for consumers, removes checkout friction for merchants.

newsroom.paypal-corp.com

Passkeys supported sites and apps

Sign In with Apple was the precursor for Passkeys. Given the way it's been engineered, it looks like all of those that have added support for Sign In with Apple will work from the get go with Passkeys – if not directly, then through Sign In With Apple which will look and act the same when...

forums.macrumors.com

 

[ztec]

1passwordilla on hyvä demo tuosta miten helppoa loginit on jatkossa:

Passkeys: the future of authentication in 1Password

How 1Password is working to make passwordless sign-ins secure, accessible, and freely interoperable.

www.future.1password.com

Olisin hotlinkannut videon suoraan, mutta eivät näköjään mokomat salli sitä.

 

[ztec]

Ihan loogista, että isot tahot pistävät kyllä WebAuthn/Passkeysin osalta vauhtia, mutta haluavat rajoittaa sen käytön vain omiin palveluihin. Ainaki esim. KeePassXC:n osalta taas aivaimet ovat vapaasti vietävissä ja tuotavissa myös muihin managereihin.

Tuo on vähän sama kuin SSH:n ja kaikkien muidenkin avaimia käyttävien palveluiden kanssa. Halutaanko käyttää yhtä avainta, ja jakaa se "kaikille laitteille". Miksei voida tehdä laitekohtaisia avaimia? Jotenkin tuo jakaa avaimet laitteille on jotenkin retroa mun mielestä. Musta on paljon parempi, että on lista laitekohtaisista sallituista avaimista, eikä toisin päin.

Täähän on vähän kuin shared passwords. Ei tarvii tehdä käyttäjäkohtaisia accountteja, kun jaetaan yhden accountin salasana kaikille. Niin, jostain syystä usein säännöt kieltää tuon käytännön.

 

[ztec]

Chrome seurasi nopeasti perässä, nyt Chromessa on passkeys login manageri, jolla palveluihin rekisteröityminen ja kirjautuminen tulee sika nopeaksi ja helpoksi:

Introducing passkeys in Chrome

We announced in October that passkey support was available in Chrome Canary. Today, we are pleased to announce that passkey support is now ...

blog.chromium.org

Kirjaudu palveluihin vaikka sormenjäljellä. Päivitetään vihdoinkin systeemit legacystä tähän päivään.

 

[Humanoid]

Chrome seurasi nopeasti perässä, nyt Chromessa on passkeys login manageri, jolla palveluihin rekisteröityminen ja kirjautuminen tulee sika nopeaksi ja helpoksi:

Introducing passkeys in Chrome

We announced in October that passkey support was available in Chrome Canary. Today, we are pleased to announce that passkey support is now ...

blog.chromium.org

Kirjaudu palveluihin vaikka sormenjäljellä. Päiviteätään vihdoinkin systeemit legacystä tähän päivään.

llmeisesti Google-tiliin saa Passkeysin vain, jos käyttää Googlen omaa salasanamanageria? En ainakaan löytänyt mistään tilin syövereistä asetusta jolla olisi mahdollista lisätä laite/Passkeys. Muutenkin aika harvella saitilla on näemmä toimiva tuki tuolle. Toivotaan, että tilanne paranee pian.

 

[ztec]

Muutenkin aika harvella saitilla on näemmä toimiva tuki tuolle. Toivotaan, että tilanne paranee pian.

Tämä on erittäin valitettava totuus. Ainoa sivusto jossa itselläni on se käytössä tällä hetkellä on Microsoftin omat palvelut. Mutta eiköhän tuo tule yleistymään vauhdilla, koska on erittäin varteenotettava, turvallinen ja edullinen (ilmainen) vaihtoehto. Kuten tässäkin langassa on käyty läpi, on monet valittanut FIDO2 avainten HSM-moduulien hinnoista. Mutta tätä myöten ne on ilmaisia, kun on käytössä softapohjainen ratkaisu. U2F on käytössä kaikkialla missä voi käyttää, mutta toki sen kanssa tarvitaan sitten vielä se käyttäjätunnus ja salasana, mistä tämä passkeys / passwordless vapauttaa kokonaan.

 

[Humanoid]

Tämä on erittäin valitettava totuus. Ainoa sivusto jossa itselläni on se käytössä tällä hetkellä on Microsoftin omat palvelut. Mutta eiköhän tuo tule yleistymään vauhdilla, koska on erittäin varteenotettava, turvallinen ja edullinen (ilmainen) vaihtoehto. Kuten tässäkin langassa on käyty läpi, on monet valittanut FIDO2 avainten HSM-moduulien hinnoista. Mutta tätä myöten ne on ilmaisia, kun on käytössä softapohjainen ratkaisu. U2F on käytössä kaikkialla missä voi käyttää, mutta toki sen kanssa tarvitaan sitten vielä se käyttäjätunnus ja salasana, mistä tämä passkeys / passwordless vapauttaa kokonaan.

Onko Microsoftin tunnuksenkin Passkeys/WebAuthn sidottu siten ettei sitä voi määrittää vapaasti? Taidanpa käydä testaamassa.

Laitetaan joulupukin toivomuslistaan seuraavat:
- Google/Microsoft/Apple/jne sallii muiden salasanamanagereiden käytön Passkeys:in yhteydessä
- Selainvalmistajat antavat kehittäjille API:n käyttöön jolla Passkeys/WebAuthn-kutsuja voi ohjata ilman likaisia scriptojen inject-kikkoja, jotta kolmannen osapuolen salasanamanagerit saavat tälle kunnon tuen

 

[ztec]

Onko Microsoftin tunnuksenkin Passkeys/WebAuthn sidottu siten ettei sitä voi määrittää vapaasti?

Ei, nämä toimii vain yhtenä login vektorina sisään. Rinnalle jää mm kirjautuminen käyttäjätunnuksella ja salasanalla, sekä app passwordit jne jne. Tuo on hirveä sotku ja suo.

Mutta käytännössä kun haluaa kirjautua palveluun, riittää että menee sivulle ja painaa että login, ja se on siinä. Ei tarvita käyttäjänimiä, eikä salasanoja.

 

[Paapaa]

Tekeekö siis passkeys kaikissa tilanteissa hardware-avaimet (ja muut 2FA-menetelmät) kuten Yubikeyn turhiksi? Tai turhiksi kaikkien muiden tunnusten kohdalla paitsi sen salasanamanagerin, joka myös pitää suojata ja joka vaatii jatkossakin master passwordin ja 2FA:n?

Sinänsä vaikuttaa kyllä lupaavalta teknologialta kunhan tuo saadaan eri managerien välillä järkevän yhteensopivaksi.

 

[mikajh]

Onko Microsoftin tunnuksenkin Passkeys/WebAuthn sidottu siten ettei sitä voi määrittää vapaasti?

Itse poistin Microsoft-tunnuksesta salasanan 10/2021 kun MSFT oli suositellut sitä jo pidempään

 

[ztec]

Tekeekö siis passkeys kaikissa tilanteissa hardware-avaimet (ja muut 2FA-menetelmät) kuten Yubikeyn turhiksi?

Kyllä ja ei. Passkeys toimii mun mielestä siinä mielessä väärin, että siinä jaetaan samaa avainta eri laitteille. Mun oma preferenssi olisi se, että joka laitteelle luodaan eri avaimet, joille sallitaan pääsy. Mutta tietty tää on ns. normikäyttäjien kannalta liian foliohattusta menoa ja niiden kapasiteetti ei koskaan riitä moiseen ajatteluun. Vrt. Teetkö SSH avaimen, ja kopioit sen joka paikkaan, vai luotko joka koneelle ja joka palvelulle omat SSH avaimet, ja sitten annat tarvittaville avaimille pääsyn palveluihin. - Yllättävän monet ei ymmärrä näiden konseptien eroja. Lopputulema on kuitenkin normikäytössä sama. Eli pääsee eri paikkoihin ilman salasanoja.

mm. Yubikey:llä on oma passkeys sivusto.

Lisäksi noissa hardware avaimissa on nimenomaisesti se etu, että sieltä ei voi tuota private keytä voi ottaa ja jakaa ympäriinsä. Jotkut jotka eivät ymmärrä tätä ideaa, ovat siitä kovasti valittaneet. Tuohan kun estää esimerkiksi avaimen varmuuskopioinnin. Oman osuutensa tietysti tähän soppaan on aiheuttanut ne palvelut, joiden keharit (sovelluskehittäjät) ovat antaneet mahdollisuuden rekisteröidä vain yhden avaimen. Kun toki pitäisi voida rekisteröidä esim, työ, koti, kännykkä ja vara-avain palveluun.

Käsittääkseni ainakin Applen passkeys ratkaisussa voi exportata private avaimen. (En ole varmistanut tätä asiaa, mutta näin monessa keskustelussa tuon mainittuna).

Tai turhiksi kaikkien muiden tunnusten kohdalla paitsi sen salasanamanagerin, joka myös pitää suojata ja joka vaatii jatkossakin master passwordin ja 2FA:n?

Sepä se. Tämä on juuri se, miksi mm. Google, Microsoft ja Apple accountit, jotka toimivat siis password / key managereina, eivät itsessään voi toimi pelkästään tuon tunnistautumisen pohjalta, vaan tarvitaan vaihtoehtoisia menetelmiä. Jotka voi olla sitten enemmän tai vähemmän hyviä.

Koska passkeys on webauthn yhteensopiva, tarkoittaa tämä sitä, että myös ne palvelut jotka eivät aikaisemmin hyväksyneet HW avaimia, tulevat tässä samalla hyväksymään myös ne. Joka on mielestäni varsin positiivista.

Edit, lisätään vielä sivukommenttina se, että passkeys loginin voi toki myös delegoida OAuth:n kautta. Eli jos sivusto tukee OAuthia, käytä kirjautumiseen OAuthia palveluntarjoajan kanssa joka tukee passkey:tä. Ei ihan yhtä kätevää, mutta vapauttaa edelleen salasanoista.

Tällaiseen kaavioon törmäsin jossain netin syövereissä. Sisältöä en ole tarkastanut.

 

[Paapaa]

Passkeys toimii mun mielestä siinä mielessä väärin, että siinä jaetaan samaa avainta eri laitteille

Tää ei oo tietenkään turvallisin vaihtoehto, mutta musta ihan perusteltu kompromissi, sillä käytännössä netin kokonaisturvallisuus nousee tässä valtavasti kun paskoja salasanoja ei voi enää käyttää. (Jos tuo yleistyy.)

Ja jos sivustot antavat liittää passkeyn kylkeen vielä HW-avaimen 2FA:ksi, niin sitten tuokin ongelma olisi jossain määrin poissa. Tätä voisi soveltaa kaikkein kriittisimpiin palveluihin.

 

[mikajh]

Päivitetään vihdoinkin systeemit legacystä tähän päivään.

Huom. Win 11 21H2 on liian legacyä Chromen passkeys-storeksi

 

[Infy]

One step closer to a passwordless future

Over the next year all major device platforms have committed to building in support for passwordless FIDO Sign-in standards.

blog.google

To sign into a website on your computer, you’ll just need your phone nearby and you’ll simply be prompted to unlock it for access.

Ai, että jos joku toinen yrittää kirjautua mun tilille, ja minä vahingossa hyväksyn sen vahvistuksen puhelimella niin se siitä sitten? Miten tämä on parempi kuin salanasana + 2FA vahvistus?

 

[mikajh]

Ai, että jos joku toinen yrittää kirjautua mun tilille, ja minä vahingossa hyväksyn sen vahvistuksen puhelimella niin se siitä sitten?

Kokeile tuota passkeys.io:n demoa niin näet.
Tosin en tiedä antaako se kovin hyvää kuvaa turvallisuudesta, kun se lähettää holtittomasti TOTP-koodia sähköpostiin. Eli jos hyökkääjällä on pääsy sähköpostiisi, niin "se siitä sitten". Tuossa nimenomaisessa demossa on toki mahdollista antaa toimimaton sähköpostiosoite, jossa tätä featurea ei ole.

 

[Infy]

En ymmärrä miten tuon demon sähköposti ja TOTP koodit liittyy tähän hypetettyyn passwordless ominaisuuteen.

Mua kiinnostaa miten turvallinen passwordless on käytännössä.
1. Mulla on joku palvelu, vaikka Google, jossa mulla on passwordless setuppi käytössä.
2. Joku muu yrittää kirjautua Googleen mun tunnuksella, ja se tietää vain mun G-mail osotteen, ei muuta.
3. Saan siitä hyväksyntä popupin puhelimeen, missä erehdyksessä vahvistan sen.
4. Se joku muu pääsee mun Google tilille?

 

[Infy]

Passkeys: the future of authentication in 1Password

How 1Password is working to make passwordless sign-ins secure, accessible, and freely interoperable.

www.future.1password.com

Tuolla videossa se on juuri noin. Hyökkääjän tarvii vaan spämmätä sisäänkirjautumista, kunnes käyttäjä lopulta hyväksyy sen päästäkseen siitä eroon.

Tosin ainakin OP:n verkkopankkiin kirjautuminen toimii juuri samalla tavalla. Vahvistus puhelimen sovelluksessa ja hyökkääjän tarvitsee tietää vain käyttäjätunnus. Tämä on tietoturvallisesti "tarpeeksi hyvä".

 

[mikajh]

En ymmärrä miten tuon demon

Jos kokeilisit, niin ymmärtäisit vähän enemmän. Ei noita ensimmäiseen kertaan liittyviä extratoimia tule sen jälkeen, kun olet omassa passkeys-yhteensopivassa laitteessa jo kirjautunut kerran.
Jos sellainen tulee, etkä ole itse tekemässä mitään, niin kyseessä on joku muu. Jos tällaisia on vaara erehdyksessä vahvistaa (jos se nyt edes onnistuu ilman lisätietoja, mitkä ovat vain hyökkääjällä), niin parempi olla ottamatta käyttöön

 

[Paapaa]

Hyökkääjän tarvii vaan spämmätä sisäänkirjautumista, kunnes käyttäjä lopulta hyväksyy sen päästäkseen siitä eroon.

Olisiko niin että kirjautumista ei voi edes aloittaa ilman passkeytä. Eli tuo ei ehkä ole lainkaan mahdollista. Sulla pitää olla se passkey eikä pelkällä käyttäjätunnuksella homma etene.

En siis tiedä. Mutta tuollainen "fatigue"-hyökkäys on ihan todellinen ongelma.

 

[Infy]

Olisiko niin että kirjautumista ei voi edes aloittaa ilman passkeytä. Eli tuo ei ehkä ole lainkaan mahdollista. Sulla pitää olla se passkey eikä pelkällä käyttäjätunnuksella homma etene.

En siis tiedä. Mutta tuollainen "fatigue"-hyökkäys on ihan todellinen ongelma.

Tuossa videolla demonstroitiin juuri kirjautumista uuteen laitteeseen. Siihen uuteen laitteseen syötetään pelkkä sähköpostiosoite, vahvistuspyyntö tulee puhelimeen, hyväksyntä ja uusi laite kirjautuu onnistuneesti sisään.

 

[mikajh]

Tuolla videossa se on juuri noin. Hyökkääjän tarvii vaan spämmätä sisäänkirjautumista, kunnes käyttäjä lopulta hyväksyy sen päästäkseen siitä eroon.

Esimerkiksi MSFT Authenticatorissa on mahdollisuus, jossa push-notifikaatiota ei voi hyväksyä syöttämätä 2-numeroista koodia, joka näytetään vain hyökkääjälle

 

[Humanoid]

Kokeile tuota passkeys.io:n demoa niin näet.
Tosin en tiedä antaako se kovin hyvää kuvaa turvallisuudesta, kun se lähettää holtittomasti TOTP-koodia sähköpostiin. Eli jos hyökkääjällä on pääsy sähköpostiisi, niin "se siitä sitten". Tuossa nimenomaisessa demossa on toki mahdollista antaa toimimaton sähköpostiosoite, jossa tätä featurea ei ole.

En tosiaan minäkään hoksaa miten tuo saitti liittyy edes Passkeys:iin, kun käytännössä se vain lähettää TOTP-koodin sähköpostiin. Ainakin näillä sivuilla tuota voi koittaa koeponnistaa: A demonstration of the WebAuthn specification ja lbuchs/WebAuthn Test

 

[mikajh]

En tosiaan minäkään hoksaa miten tuo saitti liittyy edes Passkeys:iin

Kokeile toimivassa laitteessa, vaikka Androidissa Chromella
E: Ja oikeastaan niitä olisi hyvä olla kaksi, toisessa luot passkeyn ja sitten kirjaudut ensimmäistä kertaa toisella laitteella

 

[Humanoid]

Kokeile toimivassa laitteessa, vaikka Androidissa Chromella

Tuo on rajoitettu ainoastaan tuohon yhdistelmään? Melkoinen walled garden taas Ei ainakaan uusin Chrome työpöytäkoneessa reagoinut tuohon sivustoon millään tavalla. Sähköposti vilahti.

 

[mikajh]

Ei ainakaan uusin Chrome työpöytäkoneessa reagoinut tuohon sivustoon millään tavalla.

Eipä tietenkään. Pitää odottaa vielä ainakin vuosi, että työpaikka ottaa vuoden vanhan Win11-version käyttöön

 

[=JP=]

Mutta tuollainen "fatigue"-hyökkäys on ihan todellinen ongelma.

Tosiaan, tästä on todisteena esim. vähän aikaa sitten tapahtunut Uber "hakkerointi" tapaus.

MFA Fatigue and MFA Prompt Bombing

We look at the MFA prompt bombing tactic used against Uber and others, and how businesses can reinforce their security infrastructure against such attacks

blog.hypr.com

Tietoturva kirjautumisessa on periaatteessa melkonen sillisalaatti tällä hetkellä erinäisten palveluiden/tekniikoiden/ohjelmistojen kesken...

 

[mikajh]

tuollainen "fatigue"-hyökkäys on ihan todellinen ongelma

Olisi tosiaan, mutta tämän videon kaltaista, tietoturvaltaan erittäin heikkoa vahvistusilmoitusta en ole toistaiseksi nähnyt Passkeys: the future of authentication in 1Password

 

[ztec]

Passkeys pääsi oikein iltasanomiinkin:
Chrome-selain aloitti salasanojen hylkäämisen: Tämä tulee tilalle

Mitä tuli tuhon login spammin, niin ihan sama koskee myös Mobiilivarmennetta. Joissain palveluissa edes se tapahtumakoodi ei näy, ennen kuin hyväksyy pyynnön. Joka on siitä hölmöä, että pyynnön joutuu hyväksymään sokkona. Olenkin tästä jo muutaman kerran maininnut, ja sama vika on siinä edelleen. Eli varsinkin jos hyökkääjällä on kyky tarkkailla sun toimia, se voi ajoittaa oman pyyntönsä niin, että et vaan voi tietää sen olevan väärä pyyntö.

Lisäksi Passkeyssissä avaimet on palvelukohtaisia, eli toisen palvelun avain ei käy toiseen palveluun. Tuolta osin se on taas mielestäni hyvin suunniteltu.

 

[jarhu]

Passkeys pääsi oikein iltasanomiinkin:
Chrome-selain aloitti salasanojen hylkäämisen: Tämä tulee tilalle

Mitä tuli tuhon login spammin, niin ihan sama koskee myös Mobiilivarmennetta. Joissain palveluissa edes se tapahtumakoodi ei näy, ennen kuin hyväksyy pyynnön. Joka on siitä hölmöä, että pyynnön joutuu hyväksymään sokkona. Olenkin tästä jo muutaman kerran maininnut, ja sama vika on siinä edelleen. Eli varsinkin jos hyökkääjällä on kyky tarkkailla sun toimia, se voi ajoittaa oman pyyntönsä niin, että et vaan voi tietää sen olevan väärä pyyntö.

Lisäksi Passkeyssissä avaimet on palvelukohtaisia, eli toisen palvelun avain ei käy toiseen palveluun. Tuolta osin se on taas mielestäni hyvin suunniteltu.

Mobiilivarmennetta spämmiessä on käyttäjä jo todella uuno, mikäli ei ole kirjautumassa mihinkään ja menee työntämään hyväksymään promptin sekä näppäilee vielä pin-koodinsa siihen päälle. Se, että joku onnistuu pääsemään väliin oikein ajoitetulla mobiilivarmennuksella on sitten oma ongelmansa. Siihen ei auta kuin käyttäjän tekemä varmentaminen, että oikeaa varmennuspyyntöä on hyväksymässä ja toisekseen mikäli palvelu, johon ei olla kirjautumassa pitäisi lähettää se koodi eli ei ole itse mobiilivarmenteen ongelma vaan palveluntarjoajan virheellinen toimintatapa. Paremminkin voisi olla, mutta onhan tämä hyvä suunta ainakin omasta mielestä.

 

[escalibur]

Mobiilivarmennetta spämmiessä on käyttäjä jo todella uuno, mikäli ei ole kirjautumassa mihinkään ja menee työntämään hyväksymään promptin sekä näppäilee vielä pin-koodinsa siihen päälle.

Aika yleistävä väite. Osa käyttäjistä käyttää esim Applen FaceID:tä numeronäppäilyjen sijasta, joten se sattaa napata hyväksynnän miltei lennosta. Toinen asia on tilanteet joissa kysely sattaa ilmaantua. Esim autoa ajaessa ja puhelinta rämpläävä käyttäjä voi hyvin isolla herkkyydellä painaa "joo joo", samoin kaupan kassalla, ambulanssin kyydissä, tai jossain muussa ei niin rauhallisessa tilanteessa.

Tilanne ei ole niin yksinkertainen ja helppo kuten osa meistä voisi kuvitella. Tarpeeksi laajalla spämmäysotannalla, aivan varmasti joku lankeaa turhaan kyselyyn ja vastaa "kyllä", vaikka ei olisikaan kirjautumassa mihinkään.

Asiaa voisi jossain määrin parantaa esim. Microsoftin tapaan jossa MFA-kyselyissä voidaan näyttää paikan, josta yritetään kirjautua sinun tunnuksilla. Suomessa kaupunkina monesti toimii Helsinki, vaikka kirjautuminen tapahtuisi satojen kilsojen päästä Helsingistä. Tämäkin on ehkä tyhjää parempi, koska ainakin osa "sokeista" klikkaajista heräisi tilanteeseen jos kaupunkina onkin Rio. Ideealiratkaisu olisi että tunnuksen omistaja voi jotenkin määritellä mistä päin maailmaa hänen tunnukseensa voi tai saa kirjautua. Esim 1Password tarjoaa tämntyyppistä WAF:ia. Ei täydellinen mutta äärettömän tehokas tapa torjua eksoottisimmat kirjautumisalueet.

 

[mikajh]

Mobiilivarmennetta spämmiessä on käyttäjä jo todella uuno, mikäli ei ole kirjautumassa mihinkään ja menee työntämään hyväksymään promptin sekä näppäilee vielä pin-koodinsa siihen päälle

Promptin klikkaus ei tee vielä mitään, ellei pin-koodia syötetä oikein. Spämmäysongelma ratkeaa lisäämällä häirinnänestokoodi, tein sen juuri itse

Jos tapahtumatunniste menee joskus syystä tai toisesta ohi, niin keskeytän homman ja teen kylmästi uudelleen, tarkistaen

 

[jarhu]

Aika yleistävä väite. Osa käyttäjistä käyttää esim Applen FaceID:tä numeronäppäilyjen sijasta, joten se sattaa napata hyväksynnän miltei lennosta. Toinen asia on tilanteet joissa kysely sattaa ilmaantua. Esim autoa ajaessa ja puhelinta rämpläävä käyttäjä voi hyvin isolla herkkyydellä painaa "joo joo", samoin kaupan kassalla, ambulanssin kyydissä, tai jossain muussa ei niin rauhallisessa tilanteessa.

Tilanne ei ole niin yksinkertainen ja helppo kuten osa meistä voisi kuvitella. Tarpeeksi laajalla spämmäysotannalla, aivan varmasti joku lankeaa turhaan kyselyyn ja vastaa "kyllä", vaikka ei olisikaan kirjautumassa mihinkään.

Asiaa voisi jossain määrin parantaa esim. Microsoftin tapaan jossa MFA-kyselyissä voidaan näyttää paikan, josta yritetään kirjautua sinun tunnuksilla. Suomessa kaupunkina monesti toimii Helsinki, vaikka kirjautuminen tapahtuisi satojen kilsojen päästä Helsingistä. Tämäkin on ehkä tyhjää parempi, koska ainakin osa "sokeista" klikkaajista heräisi tilanteeseen jos kaupunkina onkin Rio. Ideealiratkaisu olisi että tunnuksen omistaja voi jotenkin määritellä mistä päin maailmaa hänen tunnukseensa voi tai saa kirjautua. Esim 1Password tarjoaa tämntyyppistä WAF:ia. Ei täydellinen mutta äärettömän tehokas tapa torjua eksoottisimmat kirjautumisalueet.

Ymmärtääkseni FaceID ei toimi mobiilivarmenteen kanssa tai ainakaan oma kohtuullisen tuore SIM-kortilla oleva sovellus ei tue tuota. Mikäli kuitenkin uusille sim-korteilla on mahdollistettu integraatio sim-kortin ja puhelin os välillä, niin seison toki korjattuna.

Olen kyllä muista kohdista samaa mieltä, mutta ei päde tuohon lainaukseen, missä ainoa tapa hyväksyä on kirjoittaa 6-numeroinen pin. Ymmärrän kyllä hyökkäystavan sekä vahinkohyväksynnät esimerkiksi yöllä puolinukuksissa availee kännykkää ja kasvojen tunnistuksen kautta menee suoraan läpi. Mitä muutoin tulee tuohon spam fatiguehen, missä käyttäjä lopulta hyväksyy pyynnöt tietoisesti, niin se on tuottamuksellista piittaamattomuutta.

 

[ztec]

Linuxilla Firefox 109 hajotti WebAuthn ominaisuudet, jo tullut toinenkin päivitys ja edelleen rikki. Ai että, kylläpä on turhauttavaa. Toisaalta, kertoo siitä miten mukava WebAuthn on muihin autentikointi tapoihin verrattuna, kun ei tarvii kun nappia painaa.

Mitä tuli Mobiilivarmenteeseen ja koodiin, niin aiankin osa palveluista ei näytä kirjautumisen referenssikoodia. Eli hyvinkin voi käydä noin että menee antamaan koodin väärään paveluun / tapahtumaan, mikäli hyökkääjällä on kyvykkyys ajoittaa hyökkäys.

 

[dataaja95]

Kyllä ja ei. Passkeys toimii mun mielestä siinä mielessä väärin, että siinä jaetaan samaa avainta eri laitteille. Mun oma preferenssi olisi se, että joka laitteelle luodaan eri avaimet, joille sallitaan pääsy. Mutta tietty tää on ns. normikäyttäjien kannalta liian foliohattusta menoa ja niiden kapasiteetti ei koskaan riitä moiseen ajatteluun. Vrt. Teetkö SSH avaimen, ja kopioit sen joka paikkaan, vai luotko joka koneelle ja joka palvelulle omat SSH avaimet, ja sitten annat tarvittaville avaimille pääsyn palveluihin. - Yllättävän monet ei ymmärrä näiden konseptien eroja. Lopputulema on kuitenkin normikäytössä sama. Eli pääsee eri paikkoihin ilman salasanoja.

mm. Yubikey:llä on oma passkeys sivusto.

Lisäksi noissa hardware avaimissa on nimenomaisesti se etu, että sieltä ei voi tuota private keytä voi ottaa ja jakaa ympäriinsä. Jotkut jotka eivät ymmärrä tätä ideaa, ovat siitä kovasti valittaneet. Tuohan kun estää esimerkiksi avaimen varmuuskopioinnin. Oman osuutensa tietysti tähän soppaan on aiheuttanut ne palvelut, joiden keharit (sovelluskehittäjät) ovat antaneet mahdollisuuden rekisteröidä vain yhden avaimen. Kun toki pitäisi voida rekisteröidä esim, työ, koti, kännykkä ja vara-avain palveluun.

Käsittääkseni ainakin Applen passkeys ratkaisussa voi exportata private avaimen. (En ole varmistanut tätä asiaa, mutta näin monessa keskustelussa tuon mainittuna).


Sepä se. Tämä on juuri se, miksi mm. Google, Microsoft ja Apple accountit, jotka toimivat siis password / key managereina, eivät itsessään voi toimi pelkästään tuon tunnistautumisen pohjalta, vaan tarvitaan vaihtoehtoisia menetelmiä. Jotka voi olla sitten enemmän tai vähemmän hyviä.

Koska passkeys on webauthn yhteensopiva, tarkoittaa tämä sitä, että myös ne palvelut jotka eivät aikaisemmin hyväksyneet HW avaimia, tulevat tässä samalla hyväksymään myös ne. Joka on mielestäni varsin positiivista.

Edit, lisätään vielä sivukommenttina se, että passkeys loginin voi toki myös delegoida OAuth:n kautta. Eli jos sivusto tukee OAuthia, käytä kirjautumiseen OAuthia palveluntarjoajan kanssa joka tukee passkey:tä. Ei ihan yhtä kätevää, mutta vapauttaa edelleen salasanoista.

Tällaiseen kaavioon törmäsin jossain netin syövereissä. Sisältöä en ole tarkastanut.

EIkai passkeys sentään jaa samaa privaattiavainta joka laitteelle, tuohan olisi tietoturvallisesti täysin epäonnistunut ratkaisu, vai puhutko nyt palveluiden avaimista, jotka generoidaan käyttäjän julkisen avaimen pohjalta.

 

[dataaja95]

Sanoisin itse, että omassa ympäristössäni tulen yhä käyttämään nitrokeytä ja rautapohjaisia avainmanagereita, näin foliohattuna riippuvuus suurista korporaatioista tuossa passkeyssä ahdistaa.

 

[Paapaa]

Sanoisin itse, että omassa ympäristössäni tulen yhä käyttämään nitrokeytä ja rautapohjaisia avainmanagereita, näin foliohattuna riippuvuus suurista korporaatioista tuossa passkeyssä ahdistaa.

Passkey-tuki tulossa myös salasanamanagereihin, jolloin et ole riippuvainen esim. Googlesta tai Applesta.

 

[ztec]

EIkai passkeys sentään jaa samaa privaattiavainta joka laitteelle, tuohan olisi tietoturvallisesti täysin epäonnistunut ratkaisu, vai puhutko nyt palveluiden avaimista, jotka generoidaan käyttäjän julkisen avaimen pohjalta.

Mun mielestä jakaa, ainakin sen perusteella mitä olen dokumentaatioon tutustunut. Jos olen väärässä tämän suhteen, olen sitä mieltä, että se on varsin positiivista.

Juuri siitähän aikaisempia ratkaisuja on haukuttu, että avaimia ei voi kopioida. Niin tuossa sitten korjataan se "vika". Joka samalla tietenkin heikentää turvallisuutta. Eikä tätä sotkua yhtään paranna ne palvelut, joissa joku fiksu on päättänyt, että palveluun ei voi laittaa useampaa kuin yhden avaimen.