48 ms·
Passkeys: The beginning of the end of the password
- garganzol 4y agoPlease don't. In case of emergency, all that fancy stuff is unrecoverable - while passwords continue to work.
- FoodieFatty9 3y ago[dead]
- FoodieFatty9 3y ago[dead]
- lazyeye 4y agoMore Google tracking. I wonder if they get your device fingerprint on login too.
- CitySlicker6 3y ago[dead]
- BearMomma09 3y ago[dead]
- BearMomma09 3y ago[dead]
- Wininger5 3y ago[dead]
- Lost_cause2 3y ago[dead]
- peez_weez9 3y ago[dead]
- miss_mystique 3y ago[dead]
- BadassBaeu 3y ago[dead]
- BadassBaeu 3y ago[dead]
- CallingBoss7 3y ago[dead]
- CallingBoss7 3y ago[dead]
- QueenSpre9 3y ago[dead]
- QueenSpre9 3y ago[dead]
- HotMess23 3y ago[dead]
- HotMess23 3y ago[dead]
- FilterlessLad 3y ago[dead]
- FilterlessLad 3y ago[dead]
- CutiePieu2 3y ago[dead]
- CutiePieu2 3y ago[dead]
- ButterySocial9 3y ago[dead]
- ButterySocial9 3y ago[dead]
- OneAndOnly8 3y ago[dead]
- OneAndOnly8 3y ago[dead]
- CitySlicker6 3y ago[dead]
- GamersFever0 3y ago[dead]
- GamersFever0 3y ago[dead]
- WinningHero9 3y ago[dead]
- WinningHero9 3y ago[dead]
- YouWillLose 3y ago[dead]
- YouWillLose 3y ago[dead]
- LegendaryPlayer 3y ago[dead]
- LegendaryPlayer 3y ago[dead]
- SuperGamer2 3y ago[dead]
- SuperGamer2 3y ago[dead]
- YourAmbition7 3y ago[dead]
- YourAmbition7 3y ago[dead]
- SchoolDaze6 3y ago[dead]
- SchoolDaze6 3y ago[dead]
- LoudNProud 3y ago[dead]
- LoudNProud 3y ago[dead]
- SportyCheek78 3y ago[dead]
- SportyCheek78 3y ago[dead]
- Wininger5 3y ago[dead]
- InterruptingCow 3y ago[dead]
- InterruptingCow 3y ago[dead]
- VictoriousMan 3y ago[dead]
- VictoriousMan 3y ago[dead]
- SudokuMaster4u 3y ago[dead]
- SudokuMaster4u 3y ago[dead]
- HackerMaster5 3y ago[dead]
- HackerMaster5 3y ago[dead]
- SunnyXpeach0 3y ago[dead]
- SunnyXpeach0 3y ago[dead]
- Lost_cause2 3y ago[dead]
- Dragonborn5 3y ago[dead]
- Dragonborn5 3y ago[dead]
- Spicy_taco00 3y ago[dead]
- Spicy_taco00 3y ago[dead]
- Cloudy_days7 3y ago[dead]
- Cloudy_days7 3y ago[dead]
- Ninja_cat8 3y ago[dead]
- Ninja_cat8 3y ago[dead]
- Fishyfish32 3y ago[dead]
- Fishyfish32 3y ago[dead]
- HorribleTasks 3y ago[dead]
- HorribleTasks 3y ago[dead]
- Cuteaesthetic 3y ago[dead]
- Cuteaesthetic 3y ago[dead]
- Kawaiiaesthetic 3y ago[dead]
- Kawaiiaesthetic 3y ago[dead]
- Jinxcosplay 3y ago[dead]
- Jinxcosplay 3y ago[dead]
- MeshFresh456 3y ago[dead]
- MeshFresh456 3y ago[dead]
- Veranorooz67 3y ago[dead]
- Veranorooz67 3y ago[dead]
- DorkyDweeb2 3y ago[dead]
- DorkyDweeb2 3y ago[dead]
- HilariousRed3 3y ago[dead]
- HilariousRed3 3y ago[dead]
- Soverinowu09 3y ago[dead]
- Soverinowu09 3y ago[dead]
- Storystork790 3y ago[dead]
- Storystork790 3y ago[dead]
- Soverinowu689 3y ago[dead]
- Soverinowu689 3y ago[dead]
- Lucitabee46 3y ago[dead]
- Lucitabee46 3y ago[dead]
- Infamousxwho70 3y ago[dead]
- Infamousxwho70 3y ago[dead]
- Arcadezwade22 3y ago[dead]
- Arcadezwade22 3y ago[dead]
- Gameclord34 3y ago[dead]
- Gameclord34 3y ago[dead]
- givemethrill09 3y ago[dead]
- givemethrill09 3y ago[dead]
- ruggedhuman3 3y ago[dead]
- ruggedhuman3 3y ago[dead]
- out_lurking4 3y ago[dead]
- out_lurking4 3y ago[dead]
- tiger_hoods8 3y ago[dead]
- tiger_hoods8 3y ago[dead]
- peez_weez9 3y ago[dead]
- imma_adonis1 3y ago[dead]
- imma_adonis1 3y ago[dead]
- corden_kimmel1 3y ago[dead]
- corden_kimmel1 3y ago[dead]
- shard_rocker6 3y ago[dead]
- shard_rocker6 3y ago[dead]
- slay_hearts7 3y ago[dead]
- slay_hearts7 3y ago[dead]
- lion_ankles6 3y ago[dead]
- lion_ankles6 3y ago[dead]
- SasukeUchiha1 3y ago[dead]
- steel_rebel6 3y ago[dead]
- steel_rebel6 3y ago[dead]
- heart_stealer1 3y ago[dead]
- heart_stealer1 3y ago[dead]
- shadow_lord3 3y ago[dead]
- shadow_lord3 3y ago[dead]
- wolf_gang7 3y ago[dead]
- wolf_gang7 3y ago[dead]
- crow_srows9 3y ago[dead]
- crow_srows9 3y ago[dead]
- SasukeUchiha1 3y ago[dead]
- FairyTail9 3y ago[dead]
- FairyTail9 3y ago[dead]
- Tangy_sushi0 3y ago[dead]
- Tangy_sushi0 3y ago[dead]
- Namecheckr4 3y ago[dead]
- Namecheckr4 3y ago[dead]
- TheOneandonly1 3y ago[dead]
- TheOneandonly1 3y ago[dead]
- fabulously_your 3y ago[dead]
- fabulously_your 3y ago[dead]
- CitySlicker1 3y ago[dead]
- CitySlicker1 3y ago[dead]
- OfHearts00 3y ago[dead]
- OfHearts00 3y ago[dead]
- Irish_Lass2 3y ago[dead]
- Irish_Lass2 3y ago[dead]
- Charmed_Beauty0 3y ago[dead]
- Charmed_Beauty0 3y ago[dead]
- GloryBringer2 3y ago[dead]
- GloryBringer2 3y ago[dead]
- steelersfan5 3y ago[dead]
- steelersfan5 3y ago[dead]
- born_to_flirt 3y ago[dead]
- born_to_flirt 3y ago[dead]
- Kingofallking 3y ago[dead]
- Kingofallking 3y ago[dead]
- OneTruePerson 3y ago[dead]
- OneTruePerson 3y ago[dead]
- BadGuy4U 3y ago[dead]
- BadGuy4U 3y ago[dead]
- DungeonDevil3 3y ago[dead]
- DungeonDevil3 3y ago[dead]
- IzzaBigDeal8 3y ago[dead]
- IzzaBigDeal8 3y ago[dead]
- SoHapppyy2 3y ago[dead]
- SoHapppyy2 3y ago[dead]
- ImImpatient4 3y ago[dead]
- ImImpatient4 3y ago[dead]
- SoExcited 3y ago[dead]
- SoExcited 3y ago[dead]
- shopaholicdiva 3y ago[dead]
- shopaholicdiva 3y ago[dead]
- littlemiss 3y ago[dead]
- littlemiss 3y ago[dead]
- workofgood5 3y ago[dead]
- workofgood5 3y ago[dead]
- lusttforlife 3y ago[dead]
- lusttforlife 3y ago[dead]
- inkandpaper 3y ago[dead]
- inkandpaper 3y ago[dead]
- xoxogossip 3y ago[dead]
- xoxogossip 3y ago[dead]
- luckylucy40 3y ago[dead]
- luckylucy40 3y ago[dead]
- wanderlust02 3y ago[dead]
- wanderlust02 3y ago[dead]
- vogueandvibes1 3y ago[dead]
- vogueandvibes1 3y ago[dead]
- chicnextdoor11 3y ago[dead]
- chicnextdoor11 3y ago[dead]
- foodieforever10 3y ago[dead]
- foodieforever10 3y ago[dead]
- deadofwrite09 3y ago[dead]
- deadofwrite09 3y ago[dead]
- inkandfable2 3y ago[dead]
- inkandfable2 3y ago[dead]
- weworewhat 3y ago[dead]
- weworewhat 3y ago[dead]
- trueliving4 3y ago[dead]
- trueliving4 3y ago[dead]
- chillhouse 3y ago[dead]
- chillhouse 3y ago[dead]
- iamwellandgood 3y ago[dead]
- iamwellandgood 3y ago[dead]
- sincerelyjules3 3y ago[dead]
- sincerelyjules3 3y ago[dead]
- babynative4 3y ago[dead]
- babynative4 3y ago[dead]
- thedad56 3y ago[dead]
- thedad56 3y ago[dead]
- wearelivingart2 3y ago[dead]
- wearelivingart2 3y ago[dead]
- diet_prada1 3y ago[dead]
- diet_prada1 3y ago[dead]
- drunkbetch45 3y ago[dead]
- drunkbetch45 3y ago[dead]
- collectiveworld 3y ago[dead]
- collectiveworld 3y ago[dead]
- flyingoffmyfeet 3y ago[dead]
- biancachandon 3y ago[dead]
- biancachandon 3y ago[dead]
- flyingoffmyfeet 3y ago[dead]
- americanfailure 3y ago[dead]
- americanfailure 3y ago[dead]
- wolfcubwolfcub 3y ago[dead]
- wolfcubwolfcub 3y ago[dead]
- sweetwhimsy 3y ago[dead]
- sweetwhimsy 3y ago[dead]
- miss_mystique 3y ago[dead]
- justonemorepage 3y ago[dead]
- justonemorepage 3y ago[dead]
- daypursuits22 3y ago[dead]
- daypursuits22 3y ago[dead]
- spicysugar3 3y ago[dead]
- spicysugar3 3y ago[dead]
- activismand 3y ago[dead]
- activismand 3y ago[dead]
- sinthewild2 3y ago[dead]
- sinthewild2 3y ago[dead]
- justgoogleit 3y ago[dead]
- justgoogleit 3y ago[dead]
- gypsysoul09 3y ago[dead]
- gypsysoul09 3y ago[dead]
- jbspeakr 3y agoLots of uncritical media coverage out their and to be fair, I am also quite hyped about killing passwords. Nevertheless there is certain aspects that I believe did not get enough attention yet, the biggest potentially being the switch from knowledge to possession factors.. not sure whether everyone is aware of the potential implications. Some critical notes on Passkeys: https://www.jbspeakr.cc/fido-passkeys/ https://www.jbspeakr.cc/fido-passkeys/
- TheChaplain 4y agoAnd if you have your google account banned/disabled for whatever reason, then what?
- toomuchtodo 4y agoPasskeys should still be on your local device. Account recovery should fall back to e-mail magic link or government credential proofing (depending on data sensitivity and threat model). (manages customer IAM for a FinTech)
- garganzol 4y agoAnd when that last device dies in an accident or force major, what's next? Proofing won't work because if the solution is really as secure as it should be then neither party can have access in an unencrypted form.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- jahnu 4y agoIndeed I wouldn’t trust Google or Apple to be the only place my passkeys are stored. I’m currently a 1Password user and their upcoming support looks like it could address this issue (I’m not in any way affiliated with them) https://www.future.1password.com/passkeys/ https://www.future.1password.com/passkeys/
- sebk 4y agoSure but this currently means a virtual authenticator that puts unwrapped passkeys in the same memory as other applications, leaving only the OS and no other physical measures to protect a direct-memory read. That might be acceptable for your threat model, but no other currently adopted WebAuthn authenticators work this way other than password managers that don't want to be left out. Hopefully in the future OSs will have better APIs to allow third-party tools like 1Password to leverage hardware components like TPMs and Secure Enclaves to build a sync fabric that's not tied to the hardware vendor, but this does not currently exist and is not trivial to implement without significant consideration about phishing. I think YubiCo and password managers have a tremendous opportunity here to partner up to build sync fabrics bypassing OS vendors that might not be as incentivized to provide these APIs now, but I don't believe it's moving, currently. Additionally, when you say you wouldn't trust Google or Apple to be the _only_ place your passkeys are stored, it's likely that even if we can have third-party sync fabrics, that these will never be interoperable. I don't believe you'll be able to "export" a Passkey from your iCloud ecosystem and import it into the 1Password ecosystem as you can do today with passwords. Doing so would break assumptions about the strength of the authenticator as far as WebAuthn is concerned, and would weaken Apple's security posture as well. Instead you'd probably have to maintain _both_ sync fabrics independently with every service you sign up for.
- vlovich123 4y agoLet’s say I have a passkey in Chrome and no password. How do I add a passkey to iOS so that I can login via both mechanisms? Is my understanding correct that if I only used Passkeys that I’d be permanently locking my account to a third party service to the vendor I used to login with in the first place?
- domoritz 4y agoAt least for the Google account, it looks like you can add multiple passkeys.
- vlovich123 4y agoSure. But am I still locking my ability to access that account permanently to Google? Can I login via Chrome on an Apple/Windows platform and add a passkey there? I’m also a bit worried that this permanently entrenches these as the platform vendors because no one is going to port to a new platform unless you’re already a major tech company (maybe).
- barkerja 4y agoGoogle actually outlines that very scenario near the bottom of their announcement: > Using passkeys does not mean that you have to use your phone every time you sign in. If you use multiple devices, e.g. a laptop, a PC or a tablet, you can create a passkey for each one. In addition, some platforms securely back your passkeys up and sync them to other devices you own. For example, if you create a passkey on your iPhone, that passkey will also be available on your other Apple devices if they are signed in to the same iCloud account. This protects you from being locked out of your account in case you lose your devices, and makes it easier for you to upgrade from one device to another. > If you want to sign in on a new device for the first time, or temporarily use someone else's device, you can use a passkey stored on your phone to do so. On the new device, you’d just select the option to "use a passkey from another device" and follow the prompts. This does not automatically transfer the passkey to the new device, it only uses your phone's screen lock and proximity to approve a one-time sign-in. If the new device supports storing its own passkeys, we will ask separately if you want to create one there.
- XorNot 4y agoI hate this, I hate every part of this. The attempt to get rid of passwords has been the biggest assault on the free internet in recent history, and people are asleep at the wheel as it's happening. They want to tie you to an external service, so they can tie you to your phone, which they also manage with another external service. All of these schemes are braindead with obtuse, user-unfriendly backup/transfer/restore options. They fail at even making things "simple" for regular users.
- bsenftner 4y ago[flagged]
- deleted 4y ago[deleted]
- jmull 4y agoTo avoid being a propagandized lemming you have to have a basic understanding of what is happening... passkeys aren't tied to Google or to any other specific provider. Note that this announcement is just about Google supporting logging to with passkeys to their platform. But you don't have to have anything to do with Google to use passkeys with other sites/apps that support them.
- garganzol 4y agoDisguising a proprietary development under an industry standard umbrella is a typical move from Corporate Utopia playbook. That's why it is so easy to spot when somebody tries to manipulate public opinion using social media accounts. It would be a totally different situation if customers were actually interested in a particular solution. Otherwise, it's all astroturfing and nothing can really change that. Also it's always a good tone to put a disclaimer, e.g. "Googler".
- jmull 4y ago> Disguising a proprietary development under an industry standard umbrella is a typical move from Corporate Utopia playbook. OK, but is that what's going on here? There's the suggestion in this part of the thread that somehow this all inhibits user freedom. But these objections appear to come out of complete ignorance of what is actually happening. I'm pointing it out because it's the people who are most concerned about corporate manipulation that need to understand what's happening to have any idea on how to guard against it. > Also it's always a good tone to put a disclaimer, e.g. "Googler". I guess you're suggesting I'm a Google shill? Well, (1) you're wrong (in fact, I got rid of all the Google things I used to use personally); (2) did I even say anything helpful to Google? I suggest to take off the tin-foil hat of paranoia. It's not going to protect you from anything and, in fact, will make you more vulnerable if you let it cause you to focus on the wrong things.
- dgrin91 4y agoHow is this more secure? They say "with a fingerprint, a face scan or a screen lock PIN", but basically all phones let you fall back to PINs if you dont want to do face or fingerprints. Pins are flat out not secure - typically just 4 digits. Yeah its probably better than 80% of people having "password123", but it seems strictly worse than a password + password manager? Or at least just having proper 2FA.
- ferminaut 4y agoit's more secure on the back end. The DB will store a hashed unique pass phrase that isnt shared with anyone else. You enter a pin, the web server sees a public key that only your side has the private key to.
- surteen 4y agoBecause it's a PIN protecting a certificate stored on the device. Even if you know the PIN but don't have access to the device, you can't use it.
- toomuchtodo 4y agoAnd the pin is the same functionality as activating a hardware authenticator like a Yubikey.
- stouset 4y ago… which have historically yielded credentials at any touch, without a need for a PIN, fingerprint, or face scan.
- VoodooJuJu 4y ago>with a fingerprint, a face scan or a screen lock PIN I agree - not secure. And just a daily reminder that biometrics are usernames, they are not passwords. You can change a password, a lock, a key, you cannot change biometrics, and thus they should not be used for guarding sensitive info. The only use-case for biometrics is deanonymization, sold to you under the auspices of security, primarily used for corporate surveillance.
- dtech 4y agoIt looks like a good change for the average user, a secret stored on the device is likely a whole lot safer than just having a password. Having it as the only factor seems less secure than password + good extra factor like TOTP on device though. I also wonder how a lost/broken/replaced device is dealth with, especially given Google's less-than-stellar account lockout history. edit: I guess this is still MFA since you need both the physical device and a fingerprint and phone unlock code
- barkerja 4y agoPasskeys can also be used in addition to passwords, as a form of 2FA. I've seen a number of sites approach Passkeys in this manner. Or if you really wanted to, you could flip it. You can allow the Passkey to be the "password" and an actual password the second-factor for the user.
- hhh 4y agoI have used FaceID & TouchID passkeys for a few months now for MFA. I love it, it’s the most seamless auth for me thru PingID.
- baryphonic 4y agoI don't want to give Google my fingerprint or my face. A password in a password manager + 2FA is fine.
- tallanvor 4y agoYou're not. You're storing a private key on a device, and using something like a fingerprint or pin to unlock it and use it to authenticate. The fingerprint data is also only stored on the local device.
- awaythrow98765 4y agoYeah. Except if the usual Qualcom spy chips (also available in Google Pixel) phone home all your biometrics...
- okhuman 4y agorun your own passkey server with https://github.com/authcompanion/authcompanion2 https://github.com/authcompanion/authcompanion2
- nashashmi 4y agoSo yahoo has had this for a while. yes ... Yahoo. What's wrong with Google these days? They seem to be too focused. BTW, passkey is the name for a password that is made using word keys.
- zug_zug 4y agoWhat are the privacy implications for this? Are companies that see my passkey going to be able to link it to all my other accounts, or will each passkey be completely anonymous?
- echeese 4y agoPasskeys are unique per Relying Party, in this case, google.com can only access passkeys for google.com. They can't even enumerate them, all they can do is pop up a dialog and wait for the user to select one.
- mmcnickle 4y agoThe linked security blog post[1] has a lot more of the technical details and can clear up some of the questions/confusion that people have added in the comments. [1]https://security.googleblog.com/2023/05/so-long-passwords-thanks-for-all-phish.html https://security.googleblog.com/2023/05/so-long-passwords-th...
- wepple 4y ago+1 everyone should read that - 60% of comments on this thread are explained away by reading this.
- garganzol 4y agoThose guys should not work in identity and access areas. Period. Only one reason says everything: they provide no support. Customers will be left in the cold, minus all their belongings. But they may separate into several companies to avoid conflict of interests, if they prefer, this time with proper support and everything. Or they can be forced to do so, if they are too stubborn and will continue running their dystopian playbooks. So, the situation is not strictly technical, it's much deeper than that. A blog post won't make a dent.
- breakingrules 4y ago[dead]
- ExoticPearTree 4y agoThe advantages are very poorly explained in the article. Last time I read about this, you could use your phone or a FIDO key to authenticate. Like if the phone was close to the computer you could aithenticate the same way you can unlock your computer with your watch. So either this new technology is so advanced lesser minds don’t understand it or it jus adds a more cumbersome authentication method instead of passwords and its adoption rate will be in single digits.
- mihaaly 4y agoMy takeaway is that this is infinitly more secure for those do not care about security - the "password1234" crowd, actually their account may even be secure from them logging in from now on -, for the rest it is about the same, but different.
- teeray 4y agoI really wish these “password killers” would acknowledge that we will never eliminate passwords. Ever. There’s too many under-funded applications deployed out there that have no resources to add passkey support. Password managers are an excellent place to progressively enhance the user authentication story and could support more advanced schemes like passkeys while remaining compatible with the registry of deeds site from 1999. Instead, it’s always presented as some other thing (usually conveniently tied to Chrome) that you have in lieu of your password manager.
- awaythrow98765 4y agoActually I'd see a future where some of those password killers might replace passwords, even for some of the under-funded, under-manned applications out there. What is necessary is a robust, simple-to-integrate standard for authentication, authorization and sessions built into HTTP. Such that all the "hard work" is integrated into common HTTP server software or load balancers, transparently. From an application perspective it should just look like your request getting HTTP_USER=someone HTTP_PERMISSIONS="stuff,foo,bar" HTTP_SESSION="0xdeadbeef", similar to what you get from HTTP basic or negotiate auth, but with a few more necessary features such as session, login/out and a permission model. Browsers would have to provide some proper UI for that, not utter crap like they currently do for HTTP basic or negotiate auth. Then your centralized auth application can just talk to any old application in a very simple way, no need to deal with huge integration headaches like OAuth or stuff. And the centralized auth application can do all the fancy password killer, 2FA, magic or whatever special auth you need.
- ilyt 4y agoYeah, none of big tech wants that, they don't want to make it easy for 3rd party. Ideally there would just be standarized interface between "credential manager" and applications + some OS-enforced security (so password manager knows which PID sent the question about password or other type of credential). Then we could have say pub/privkey or cert based authentication implemented there, app just asks for a credential for a site and cred manager asks user whether to allow it once or forever, and which credential to give. The app then could garnish that with extra metadata so say firefox container feature, or different firefox profile could attach metadata about from which container or profile the request comes from, and credential manager could hand out different credentials based on from where it came.
- breakingrules 4y ago[dead]
- gst 4y agoJust a heads-up if you're planning to use passkeys with iOS/macOS: Might be fixed already, but last time I tried it out it seemed like iOS only stored a single passkey per domain. If you first store a passkey for a@domain and then later on store a passkey for a different user b@domain the a@domain passkey is overwritten without any warning. Or at least this seemed to be the case a couple of months ago when I tried it out.
- asimpletune 4y agoFor me at least it works. I have multiple accounts for the same domain and iOS/macOS prompt me to choose from the last one used, or I can choose to pick from a collection.
- judge2020 4y agoAll the way back in iOS 15, when getting passkeys meant building an xcode app to access the developer menu and enable passkeys, I had no trouble storing multiple per domain when adding passkeys to GitHub. Maybe the site you were trying to use sent the same `user.id` for both requests? /shrug
- ezfe 4y agoThat would only happen if the site isn't properly giving the passkeys identifiers. Having single passkey/username combo is working as intended, but it shouldn't be overwriting different usernames.
- segmondy 4y agoI'm still salty about this. Called it passkey too. http://www.multipasskey.com/susdemo/ http://www.multipasskey.com/susdemo/. Built this 5-6yrs ago and applied to YC. Crickets. Hope to see this take off, with my approach I made it where you don't even need to "register", you can go to a site and just have an account. I did the fingerprint, face scan, PIN approach for more security, but my favorite was NFC ring. Basically you have an NFC ring you wear on your finger. That way if someone steals your phone or takes it, you are protected. The entire thing uses a unique pub/pri keys for each site. Keys are backed up by shamir secret sharing distributed across your friends or providers you select. 100% of your keys are encrypted so I the provider can't see it, recover it or be forced to reveal it. Since each site has a key, one could do interesting things. E2E encryption for apps where they can't be forced to reveal a key. If you are using an App and want to send someone a message, the app can fetch the person's pub key, then an inbuilt editor outside of the App in our app will be used to compose the message and encrypt it. That way the App provider can't be forced to reveal the message, and they don't have keys either. Pretty much control in the hands of the user. The same approach can be used for a storage pod where you have a pod that stores your data that you encrypt and control. This is a good start, hopefully we can see the good ideas of this, AT protocol (account portability), keybase, etc all start to bear fruit. What I don't like bout Google doing this is that the big providers use this to tether and lock you in to their platform. The power of this shines when it's federated. So if you run a site, you can provide security to your users without them needing Google, FB, etc.
- djbusby 4y agoI love this approach.
- hdiehdis 4y agoi say this every time this is mentioned... all these thing are mostly to help advertisers and fight spam and reduce cost on their servers. theres a million ways to provide this functionality without relying on vendor lock in. they are pretty much working as a mini certificate authority/vendor. instead of vetting clients and giving them CAs, they just run your credit card for some hardware or subscription, and validate your login.
- red_trumpet 4y ago> passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes. What is the scenario in which SMS one-time codes are prone to fishing, but passkeys are not?
- neilalexander 4y agohttps://en.wikipedia.org/wiki/SIM_swap_scam https://en.wikipedia.org/wiki/SIM_swap_scam
- jefftk 4y agoThat is also an issue with 2fa sms, but it's not phishing.
- neilalexander 4y agoPhishing is quite often how a SIM swap attack starts.
- red_trumpet 4y agoYeah okay, but then just don't do 2fa via SMS. How are passkeys better than a 2fa app on my smartphone?
- wepple 4y agoPasskeys sign a web origin. If you try to phish one, the token you get won’t be valid for the origin you’re trying to authenticate to. Eg you’ll get: Token{domain:hax0r.net username:bob}
- jefftk 4y ago1. You're tricked into visiting evil.example and don't realize it. 2. evil.example: confirm 2fa code to log in. 3. evil.example starts logging into good.example as you, triggering good.example to send the 2fa code. 4. You see the 2fa code and enter it into evil.example. 5. evil.example has phished your 2fa code. This doesn't work with passkeys (or 2fa tokens) because those verify the domain matches.
- Armic 4y agoWhat happens if you lose all your hardware factors (eg if you have a home fire)? Are you just locked out of all your accounts with this approach?
- barkerja 4y agoNot if the Passkey was synced (ex: you used iCloud keychain). If the passkey was not synced, then I would have to assume it would be the same if you lost a physical hardware key.
- Gasp0de 4y agoHow do you access iCloud without your passkey?
- warkdarrior 4y agoCall Tim, he'll vouch for you.
- barkerja 4y agoI use a yubikey. But AFAIK, Apple doesn't actually use passkeys for iCloud/Apple ID authentication.
- Gasp0de 3y agoNot yet, but Google wants them to become ubiquitous. So in that (far) future, backing your passkeys up in a cloud (that is also protected by passkeys) doesn't help
- ezfe 4y agoApple account recovery supports setting a recovery code or having a friend listed as a recovery contact. Apple does not yet support Passkey for iCloud accounts login.
- AlexandrB 4y agoComplain loudly on Twitter and hope your tweet goes viral.
- kmlx 4y agoi’ve got passkeys enabled on github, cloudflare, google, twitter etc via apple’s passkey implementation (https://support.apple.com/en-gb/guide/iphone/iphf538ea8d0/ios https://support.apple.com/en-gb/guide/iphone/iphf538ea8d0/io...). they all implemented passkeys as an alternative to sms OTP. very easy to use, and should be better than sms, but still haven’t seen full on login using passkeys. if anyone knows of such a site i’m curios how they implemented it.
- awaythrow98765 4y agoThose passkeys are either insecure or unreliable. Let me explain: Those passkeys are asymmetric cryptographic keypairs where the private key is securely stored on a device, unlockable (for use, not reading) only by convincing your devices security processor to do so by pin/fingerprint/pattern. Which in itself can be secure, given you do trust that magic security processor (which you shouldn't, see yesterday's news for example). However, if that key cannot be read, you cannot make a backup of it, so it will be unrealiable and easy to loose. The recovery process will either be insecure and prone to social engineering, or unreliable because proving your identity will be nigh impossible without that passkey. Now one could allow backups of a passkey, but then that passkey would be as insecure as a password. One could allow multiple instances of authorized passkeys, but those would be even more insecure than passwords, because malicious software on your device could create evil new key instances. In all a bad and dangerous idea.
- Shank 4y agoThe point of passkeys isn’t to be perfect — the point is to replace passwords, which are already far more imperfect than passkeys. The bonus points with a password is that every site that uses them has to secure them properly and theft of passwords, in plain-text, hashed, etc form is common.
- awaythrow98765 4y agoFor an end-user, reliability and ease-of-use trump security. Passkeys are imperfect in the wrong places imho.
- XorNot 4y agoImagine for a moment that instead of all the time wasted on this, we just implemented a protocol amongst the browser makers which allowed a secure password prompt to be requested, and required strong-hashing before sending anything over the wire? Which would be easier to use and more effective.
- doodlesdev 4y ago
- cbeach 4y agoAnyone know if it's possible to use this with Google Workspace accounts yet? From the Google Blog I clicked on "Today, passkeys for Google Accounts are available. You can try them out here" However, I got: "Passkeys aren’t allowed on this account. Contact your admin for help" And the Workspace admin page doesn't seem to include any options for Passkeys.
- dhess 4y agoSame here, but note that in this post on the Google Security Blog: https://security.googleblog.com/2023/05/so-long-passwords-thanks-for-all-phish.html https://security.googleblog.com/2023/05/so-long-passwords-th... the first sentence reads, "Starting today, you can create and use passkeys on your personal Google Account." (Emphasis mine.)
- tytso 4y agoDisclaimer: I work for Google but nothing I say here is Google's opinion or relies on any Google internal information. I'm not surprised that Workspace accounts weren't included in the initial rollout. Workspace setups have interesting requirements that aren't necessarily there for personal accounts. For example, under some circumstances, if an employee gets hit by a bus, and there is critical business data which is stored in the employee's account, an appropriately authorized Workspace admin is supposed to be able to gain access to the employee's account. But what is the right thing to do for passkey access? Especially if the user uses passkey to authenticate to some non-:Google resource like, say, Slack which has been set up for corporate use? Should the workspace admin be able to impersonate the corporate employee in order to gain access to non-Google resources via passkey? What about if the employee (accidentally) uses their corporate account to set up a passkey to a personal account, such as for example E*Trade? Maybe the Workspace admin should have a setting where passkey creation is disabled except for an allowlist of domains that are allowed for corporate workflows? It's complicated, and if I were the product manager, I'd want to take my time, understand all of the different customer requirements (where customer === the Workspace administrator who is paying the bills) before rolling out support for Workspace accounts.
- Nextgrid 4y agoHow do you handle delegation in this case? Let's say I want to delegate access to my account to a partner/friend/employee on a service that doesn't support multiple users per account, charges extra for it or outright doesn't want me to delegate access to someone else (so it's not always possible to rely on the website's cooperation). Currently I can just message them the password or even write it down on a post-it note and they'll have everything they need to complete the task as me. How does it work with passkeys? Does the spec allow my passkey HSM to securely share the secret by encrypting it against the recipient's passkey HSM? Can it use the concept of leaf certificates to sign a short-lived certificate allowing access to that credential without sharing the credential's secret itself? I can't advocate for passkeys until the concerns above are resolved. The push for passkeys seems like yet another attempt to remove control from the user.
- arnarbi 4y agoYou can create a passkey for your account on their device, e.g. by selecting "Use another device" when creating it, and scanning the QR with their phone (their phone does not need to be signed in to your account). And if you both use iOS, you can Airdrop a passkey: https://support.apple.com/guide/iphone/share-passkeys-passwords-securely-airdrop-iph0dd1796bb/ios https://support.apple.com/guide/iphone/share-passkeys-passwo...
- kevincox 4y agoThis is what I love about passwords. They are tangable and understandable. I would have loved if we could move towards a solution that has the benefits of passkeys (prevents phishing, strong secret, doesn't seen the secret to the server) without ditching the underlying secret being a somewhat human-readable password. It seems that in-browser password-managers get us 99% of the way there. I would have loved to do something like adding a PAKE system to regular passwords rather than a new system built on top of non-human readable keys. I'm sure we will gain the ability to dump the key to a file or write down onto paper at some point but it seems that we are starting from the wrong end.
- jmbwell 4y agoAlso tangible and understandable is a registry of users who have access to your accounts, that allows you to grant and revoke access (at possibly different levels), without having to reset all your own credentials. I've got to quit commenting, but humans are undeniably the weakest link in security. While I understand the perceptions and even share some of the concerns expressed in this thread about the loss of control, reverting to a human-readable string as a key would only regress the whole scheme to something that is, once again, as easily compromised as a system protected only by any other human readable string. We just have to cultivate new habits. Enroll multiple keys or devices. Print the backup codes and put them in the fire safe with your birth certificate. Give trusted friends and family access to recover your account in the event you lose the credentials or get hit by a bus. It's a few extra steps up front, but once it's working, it's so much easier. Honestly, there are so many people who never have any idea what their password is, so they end up resetting it all the time... passkeys is a net-positive. Now they don't even have to remember anything.
- albybisy 4y agothe only thing that i don't like about login with passkeys is that i need to turn on the bluetooth.
- rainworld 4y agoSee also https://passkeys.directory https://passkeys.directory
- dblitt 4y agoI still don't understand how the QR code flow works with using/creating passkeys on other devices. It seems it uses a bluetooth connection to your phone, but I can't find much documentation about the exact protocol
- sebk 4y agoIt's called hybrid transport, and the old name for it was caBLE. Yubico has a nice explainer here: https://developers.yubico.com/WebAuthn/Concepts/Hybrid_Flows/High_assurance_hybrid_flows/ https://developers.yubico.com/WebAuthn/Concepts/Hybrid_Flows... It's not fundamentally different than other transports for other roaming authenticators like a USB key; the QR code sets up a BLE connection between both devices and presents the authenticator with a challenge for it to sign and log in the originating device.
- aboringusername 4y agoWhat are the legal implications of passkeys? Are there any case law examples yet? My understanding is it's 100% impossible to 'prove' I know a password or not as it could be written on a piece of paper somewhere, and it's entirely possible for that paper to be shredded and therefore any proof of that password is gone, forever. I remember hearing you cannot be compelled to hand over a password. Biometrics et al on the other hand? Could/would a judge compel those to be disclosed? I saw a video of a police officer forcing somebody to use their face to unlock their phone to delete a video. With a password, this would be 100% impossible. So yeah, think about that BEFORE using.
- Scion9066 4y agoYou don't have to enable the biometric part of this as you can still protect your device with a passcode/password only if you want. I just tested it and was able to use it with just my device PIN, no biometrics. The part about not being able to be compelled to hand over a password or decrypt something is also not true in many parts of the world. See: https://en.wikipedia.org/wiki/Key_disclosure_law https://en.wikipedia.org/wiki/Key_disclosure_law
- Gasp0de 4y agoThere is a legal advantage that passwords have that passkeys and FIDO and so on do not have. In civilized countries, no one can force you to hand over a password (as you have a right to not incriminate yourself). That does not hold for property which can be confiscated or even biometric attributes which can be taken against your will legally. Theoretically, passkeys could still offer this advantage if they are stored exclusively on my phone which is encrypted and secured with a password.
- oasisbob 4y ago> In civilized countries, no one can force you to hand over a password (as you have a right to not incriminate yourself). Which countries? In the US, the intersection between 5th amendment rights and password disclosure is not complete. You can be forced to disclose a password in certain circumstances here.
- themoonisachees 4y agoPretty much only the US explicits this right. I know France tacks on more charges to protesters who refuse to unlock their phones when arrested.
- Hamuko 4y agoHas that been tested with the ECJ yet?
- stinkytaco 4y agoI think in Florida v. Voigt someone was sentenced to 6 months for not handing their iPhone password in an extortion case. If I recall, the phone was ultimately hacked to get the evidence.
- croes 4y agoAnd if you don't comply? With biometric data like FaceId or fingerprint it's easier for them to get access.
- 4y ago
- psanford 4y agoI was expecting this also meant that I could add a FIDO2 resident key as a passkey, but the google UI currently does not allow me to do that. That's fairly disappointing. Its also fairly surprising that desktop UI on linux tells me I can't add passkeys from it. I understand that Chrome isn't planning on supporting platform authenticators on linux, but why can't I add another phone from the desktop with the QR flow?
- jlnho 4y agoI enabled passkey and literally nothing changed. Signed out and back in again several times.
- ezfe 4y agoYeah, it's not doing anything for me either
- lars_francke 4y agoDoesn't work here either. But I'm on Firefox on Linux, both of which are not yet supported as per the docs. Firefox might get it around version 120: https://connect.mozilla.org/t5/ideas/support-webauthn-passkeys/idi-p/14069 https://connect.mozilla.org/t5/ideas/support-webauthn-passke...
- falcolas 4y agoAuth is as secure as the weakest link - in the case of this it's your email and/or customer service To put it another way, it's not really any more secure than passwords. Sure, there's a lower risk of password breaches, but if you're the target audience for passkeys, you probably also use a password manager with unique passwords per site (even if that manager is the one built into your browser and synced across your devices).
- judge2020 4y ago> but if you're the target audience for passkeys This is the difference. With the big players pushing it, including Apple instructing developers on the best way to integrate passkeys in their apps[0], it's going to overall shift more people from passwords to passkeys (especially when developers prioritize passkeys during signup). 0: https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys https://developer.apple.com/documentation/authenticationserv...
- falcolas 4y agoI have... doubts. Already webauthn isn't prompting for passkeys on Apple. Chrome wants a bluetooth connection out of the box, and firefox does its own internal auth path that doesn't involve the OS. Chrome and Edge on Windows are the only ones that prompt me for passkeys today (Firefox tries to use Windows for auth, which throws up a scary prompt).
- judge2020 4y agoI don't follow for these > Already webauthn isn't prompting for passkeys on Apple. It does for me on iOS, at least (and Safari on MacOS; other browsers don't use the native icloud passkeys, chrome has its own secret store). > Chrome wants a bluetooth connection out of the box, IIRC it works without it for on-device passkeys, but caBLE requires Bluetooth to facilitate proximity passkey connections if you want to use wireless webauthn.
- 4y ago
- karaterobot 4y ago> the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN I am not a cryptographer: why would a 6-digit screen lock PIN with this system be any safer than a 6-digit numeric password on the web (i.e. not very)?
- Scion9066 4y agoGenerally, most devices don't encrypt/protect your data with that 6-digit PIN directly. They store the important secrets like device encryption keys in some kind of secure enclave/processor that does things like rate limit the PIN attempts to prevent brute-forcing. What the fingerprint or face scan is doing is just unlocking that secured data a different way.
- croes 4y agoMany phones block access after too many false PINs, if the web password has the same feature there is no difference.
- alwaysbeconsing 4y agoIn order to exploit the 6-digit password across the web, the attacker needs 1) the password, 2) web access from anywhere in the world. To exploit the PIN guarding your phone, the attacker needs 1) the PIN, 2) your phone. You can't prevent the attacker from having access to the internet, but you are probably reasonably good at protecting your phone physically.
- seti0Cha 4y agoIf your physical device can be unlocked remotely with a 6 digit number, not much, but that's not generally the case.
- ghancock 4y agoI wrote about my experience with passkey support on other services here: https://news.ycombinator.com/item?id=35758918 https://news.ycombinator.com/item?id=35758918. That experience was mostly negative. For anyone implementing this, the user experience matters and requires usability testing of a lot of combinations. In comparison to those, Google’s support seems better. It worked, was transparent about what was going on, and gave me the option to create the key on either the device I was using or another one if I wanted. The one hitch was that when I already had a 2FA key on the same platform authenticator, it just said I already had a registered key on this device and didn’t do anything. I would have expected some sort of upgrade flow for people who previously registered their devices for 2FA, or at least to more directly tell me to delete the existing security key on the device (which is what I did, and which worked).
- judge2020 4y ago> it just said I already had a registered key on this device Is this Android? Because, before this change, there was no way to register a real WebAuthn-based passkey with Google, at least when I was trying with chrome (it did not prompt the webauthn popup, just the OS-native security key popup).
- ghancock 4y agoThis was on an iPad. My experience before had been that I was able to register an iCloud passkey for Google 2SV when using Safari on iOS/iPadOS, but I was unable with Chrome. At that time, I inspected the registration request Google sent to Chrome and found it was passing a private option that Chrome recognized. According to what I found in web searches for it, the option created a legacy U2F key, and they needed to do that because there were existing Android devices that they could not upgrade and that would not support log-in with WebAuthn keys.
- hk1337 4y agoI don't mean this to be negative as much as an observation but it seems like it's Google's version of "Sign in with Apple ID"? Apple ID only works with Apple devices though, so I wonder if will work for any device? Perhaps it will work better on Android but can be implemented for other devices?
- judge2020 4y agoNo. This is the fido2 / webauthn standard, where the device itself generates new keys for each website and the device uses these stored keys to perform public key authentication to log into websites. For some ecosystems (namely iCloud Keychain) it syncs these key pairs between devices. They already have "sign in with google" which directly links sites to your Google account. This is not that.
- lxgr 4y agoWebAuthN is great, but I can't help but feel that Passkeys are actually a step backwards. At least on iOS, there is no way of preventing them from being synced to iCloud, which is the opposite of what I want for high-stakes credentials like bank accounts or government e-signatures. I've tried to raise [1] a related issue (i.e. the inability for relying parties to opt out of credential syncing, if not an explicit requirement to opt in to it) to the W3C WebAuthN working group, but it seems like the working group itself is strongly pro cloud synchronization as well. Today, Google has sent me an email about their intention to deprecate their (device-bound) iOS authenticator in favor of (iCloud-synchronized) Passkeys, and I guess I'll begrudgingly have to switch to using an external FIDO authenticator instead. [1] https://github.com/w3c/webauthn/issues/1714 https://github.com/w3c/webauthn/issues/1714
- toomuchtodo 4y agoHow is this different than a password manager with encrypted cloud backup? Your recourse if someone breaks passkeys is legal, not technical. Security must be a balance with functionality, and this is a huge improvement over passwords. (Tangentially, it would be great if we got cryptographic digital identity cards like Estonia has for signatures but that’s more of a long term goal) Cloud sync (encrypted!) is important because your average user needs that convenience and durability of authenticator.
- lxgr 4y agoThe difference is that I can choose my password manager on iOS (and thereby pick my desired security level for password synchronization or opt out of it completely), but not my Passkey synchronization backend: iOS forces these to be stored in iCloud Keychain. (Passkeys are unavailable without iCloud Keychain [1]!) Ideally, there would be a per-passkey UI option to opt out of synchronization at creation time. > Security must be a balance with functionality, and this is a huge improvement over passwords. Sure, but I'm somewhat disappointed that the WebAuthN WG basically forced this huge change of semantics (it's essentially a security vs. availability tradeoff) into relying parties without explicitly collecting their opt-in beforehand, or even providing an ergonomic way of opting out. [1] https://support.apple.com/guide/iphone/sign-in-with-passkeys-iphf538ea8d0/ios https://support.apple.com/guide/iphone/sign-in-with-passkeys...
- jrm4 4y agoI'm glad most people here are recognizing that this is a stupid, stupid idea. Here is some simple old-school ammo against it (or perhaps in favor of it, if they were to be so bold) Some good old-fashioned "skin-in-the-game" e.g. Nassim Nicholas Taleb style. I will gladly use (and pay for!) this, but only with indemnification. Insure me to the tune of, say, $100,000 in the event of a breach or a problem and not only will I use it, I'll pay for it. Otherwise, no deal. If e.g. Google wouldn't take this theoretical (or practical) deal, then they are completely full of it.
- jamesdepp 4y agoUntil there is a viable way to sync passkeys between all devices, all platforms, and all browsers, I will be happily sticking to my passwords. The security benefits provided by passkeys are not enough to offset the ecosystem lock-in that passkeys cause.
- CharlesW 4y agoWhat ecosystem lock-in are you talking about, exactly? I just created a passkey for Chrome on my macOS desktop and another on iOS. The Chrome passkey will sync to Chrome for Windows, my iOS passkey will sync to my other Apple devices, and I can create more as needed.
- jamesdepp 3y agoFor every platform/ecosystem you are using (Chrome, Apple iCloud), you had to create a new passkey. For people using multiple different devices and platforms, this is a headache. I want to sign up once and be done with it.
- CharlesW 3y ago> I want to sign up once and be done with it. Definitely! My understanding is that this is where passkey/password managers enter the picture. My preferred password manager is 1Password, so once it gets passkey support I imagine I'll use that for everything. Until then, I'm depending on the limited sync functionality in iOS/macOS and Chrome.
- jamesdepp 3y agoAgreed. If mobile operating systems allow password managers to support Passkeys, and password managers implement the functionality, then I will absolutely switch.
- alberth 4y agoDumb questions: 1. what's the backup login mechanism when you lose your mobile device? 2. with Passkeys enabled/used, will this stop google from randomly locking my account because I happen to be a person who travels a lot and they constantly think I'm a fraudster attempting to log into my own account. 3a. can I use my google passkey for logging into non-Google sites? 3b. can I use my google passkey (biometric) to log into sites that don't accept "Sign in with Google"? (meaning, other sites tap into my same enrolled passkey biometric) 4a. is the way to think about Passkey is that, it's basically turning your mobile device into an open-standard Yubikey? (meaning, Yubikey is a hardware biometric that you need to be in possession of to login. Passkeys turns your mobile phone to functionally perform the equivalent of Yubikey) 4b. Or is the way to think about passkeys is that’s it’s effectively just a password manager (like 1Password) that you use your biometric to unlock? 5. is FaceID a "passkey"? 6a. can a Passkey be paired with a mobile Drivers license, to effectively create an eID? 6b. if so, would this be a competitive threat to all the KYC offerings that exist in the world (because now you have a verified biometric login that can be used for new account openings)?
- lxgr 4y ago> 1. what's the backup login mechanism when you lose your mobile device? Passkeys are synced to the cloud by default on iOS and Android, which is probably a good idea for many use cases, but might not be what you want in some instances. > will this stop google from randomly locking my account because I happen to be a person who travels a lot and they constantly think I'm a fraudster attempting to log into my own account. Probably not, but it will make it much easier to log back in – you won't even need to type your password if you use a 2FA-capable authenticator/passkey. > 3a. can I use my google passkey for logging into non-Google sites? No, a Passkey is bound to a website. But you can create as many of these as you want.
- hedora 4y agoLike the commenter you are responding to, I still don't understand how any of this can possibly work in practice. > Passkeys are synced to the cloud by default on iOS and Android, which is probably a good idea for many use cases, but might not be what you want in some instances. OK, so how do I use my cloud synced passkey to log on to my Google account (which no longer has a password or other secret that I can back up locally) after I lose my phone? > Probably not, but it will make it much easier to log back in – you won't even need to type your password if you use a 2FA-capable authenticator/passkey. OK, but if the account is locked, that just gets them to display the "you're screwed" screen faster (since they don't need to wait for me to type a password), and the blast radius goes from just my Google account to all my other accounts, right?
- mark242 4y agoI don't know if this is the correct tactical implementation, relies upon having a cloud-based account that never goes away or gets disrupted in any fashion etc etc etc etc. However! If you have built any product which has gotten traction, you know just how much of a pain auth still is in 2023. It will always be your number one customer service pain point -- either unable to remember the email address your users signed up with so they can't initiate a reset password flow, or not getting an OOB email to start said flow, and so on. Auth in its current state is a complete drain on company time, resources, and money. Extrapolating out, I really wonder what a raw cost of the world's total GDP is taken up by dealing with auth issues. Any kind of breakthrough here would be such a net benefit to the human race as a whole. Even the half step of OAuth, even with all of its complexity and "did I use Google or Facebook or Apple to sign into this site?", even that reduced friction enough to be such a material benefit to customer service. If we can make signing into a service as easy as unlocking your phone, there would be a huge productivity jump.
- bwanab 4y agoAnd once again, with a Google Workspace (or whatever they call it these days) account, "Passkeys aren’t allowed on this account. Contact your admin for help". I am the admin. Doesn't appear there's any way to help.
- arunc 4y agoIt seems like passkey isn't available for Google Workspace yet. (I'm a Google Workspace admin as well).
- zuccs 4y agoPaying customers can't use this feature. > If you have a Google Workspace account through your school or employer, you will not be able to use passkeys to sign in at this time. Source: https://support.google.com/accounts/answer/13548313?sjid=5075895385544129981-AP https://support.google.com/accounts/answer/13548313?sjid=507...
- SadWebDeveloper 4y agoThis looks and feels like passwords with extra steps... I mean now i need to "store, manage and secure" my per-user-certificate sorry "my passkey" myself and if its get compromised its my fault, how are passkeys more "secure" than enforcing a secure long password that the user can't change unless he met certain conditions and its conveniently stored inside the password manager i just built. What happens if i lost all my devices due to a fire? at least a password let me still access things we these i might need to prove again that i am me, it might even be more easy to steal accounts because i can ask google to change it because i lost my passkey.
- dcow 4y agoThe solution, for you, is a cloud synced passkey manager, possibly a custodial one. A password manager with strong passwords is weaker than a password manager with passkeys, because passkeys use asymmetric crypto and passwords+2fa involve exchanging a shared secret over an insecure channel at some point (yes I'm considering 1-sided TLS an "insecure" channel here). Trust the security experts when they say passkeys are more secure. Now, solving the UX to make it match that of passwords plus managers today is the problem, agree.
- lxgr 4y ago> The solution, for you, is a cloud synced passkey manager This is in fact the only possible solution you get on iOS, and the default solution on Android.
- compiler-guy 4y ago> Trust the security experts when they say passkeys are more secure. I trust the security experts when they say passkeys resist various attacks better than current systems... > Now, solving the UX to make it match that of passwords plus managers today is the problem, agree. ... but poor UX makes it likely the users will end up doing things that are less secure, not adopting them at all, or messing things up themselves in such a way that they lock themselves out of their accounts. So until the UX issues are fixed, "more secure" only in the narrow definitions that sophisticated security folks worry about. If the folks I support blow it, it doesn't matter that some mostly theoretical MITM attack was prevented.
- tommiegannert 4y agoI just started looking into WebAuthn this week, and was annoyed that there is no simple way to begin: Chrome (on Ubuntu) doesn't provide a local authenticator, unless you use an emulated one. This means any site that wishes to use WebAuthn can't just say "let's do it for everyone," because not everyone might have a phone they want to use, or a security key. I found out [1] that WebCrypto + IndexedDB is pretty much the missing piece, where you can store/retrieve a generated CryptoKey without having access to the private data. I wish the WebAuthn API would handle that for me... The end-result is likely that everyone is using WebAuthn as a 2FA, rather than a password replacement, because on-boarding seems to suck right now. [1] https://stackoverflow.com/a/49479890 https://stackoverflow.com/a/49479890
- galaxyLogic 4y agoDoes this basically means there is one "master password"?
- eviks 4y agoSince you lose the "something you know" factor with passkey-only authentication (e.g., with face scans), would it not be better to allow to add a (much shorter due to the passkey) password as well as an optional extra factor?
- iLoveOncall 4y ago> Instead, passkeys let users sign in to apps and sites the same way they unlock their devices: with a fingerprint, a face scan or a screen lock PIN. So, for the vast majority that does not have hardware that supports fingerprint reading or face-scanning, this grand new alternative to passwords is... passwords? I get that it's nice for phones, but that's only about 50% of the web's traffic.
- Scion9066 4y agoIf you don't use biometrics then it's passwords or passcodes to authenticate to the local device or a secondary device to unlock it. After that it uses public key cryptography to do the actual authentication with the site you're trying to log into. At no point does the site need to have access to anything secret, unlike traditional passwords.
- nilsbunger 4y agoHow do you do account recovery if you run a service using passkeys? 1. email-based "reset passkey" flow -- only as secure as the email it's sent to, and you need to make sure the email is still valid since the user isn't using it regularly as part of their auth. 2. multi-factor "reset passkey" flow -- you have to make sure the user has kept multiple factors (eg backup codes) which they're mostly not using. Is there something better? Anyone have a good resource?
- sys32768 4y agoCan we call it something other than passkey? That sounds suspiciously like password, but makes me picture a key fob. Biometics? Authentication device?
- Scion9066 4y agoPretty sure that's intentional. It's replacing something you know (a word) with something you have (a key stored on a device or some kind of account). It doesn't necessarily need to use biometrics or be bound to a specific device, so those aren't quite accurate. Thus, passkey.
- blep-arsh 4y agoIt seems there's no way to prevent an Android device from creating and registering a passkey when signing in to a Google account on the device. Also, once you opt in, there's no way to opt out of using passkeys except by signing out of all Android devices. Great. Entrusting my Google account to my Fiio MP3 player for safekeeping was exactly what I was looking for.
- chunk_waffle 4y agoForgive me if I sound dense but you would still want a password to unlock the private key, right? Otherwise, authentication is just "something you have" not "something you know + something you have." In which case, this headline might really mean "The beginning of the end of the password on the web".
- Springtime 4y ago> And, unlike passwords, passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes. It's a bit disappointing seeing them re-affirm SMS as a a more vulnerable form for 2FA when Google's stance has been to try and force a phone requirement on Google accounts that lack them in order to login—and then using the phone for SMS 2FA. In the past number of years only after a phone is attached do other 2FA methods like TOTP become accessible as options. However even when a phone is added Google continues to utilize SMS 2FA over them for what are deemed important actions like Takeaway or auth keys, in my experience. This is despite known issues like SIM swapping, lock screen messages (viewable by anyone with device access) and due to the prevailing use of SMS for 2FA users have been prepped to accept security codes via messages which is arguably more exploitable than app-based TOTP in scams where fraudulent messages are known to be used alongside calls to mislead users into gaining trust then subsequently requesting a real 2FA message[1]. [1] https://robertheaton.com/almost-scammed/ https://robertheaton.com/almost-scammed/
- tialaramex 4y ago> In the past number of years only after a phone is attached do other 2FA methods like TOTP become accessible as options. I do always see these comments on HN and I think "Huh, really?" and I go check and, nope, Google doesn't have my phone number, but they do know I have security keys, so that's all working as intended.
- shortcake27 4y agoI don’t have my phone number “registered” with Google. IE it does not appear in my account. A few years back I was logging into a new machine from a known network. I provided the correct username, password, and TOTP on the first try. Google then forced me to authenticate further by providing my phone number _in the sign in flow_ to receive an SMS. This is pure theatre as I could have provided any number. No security was gained. Google does, however, now have my number. Even if it isn’t displayed on my account.
- discerning_ 4y agoDoesn't support yubikey even though yubikey supports fido2 and passkeys.
- eikenberry 4y agoI'm curious how free software users will be able to take advantage of this improved security. Seems tied pretty tightly to proprietary systems and I wonder if, as a free software user, I'll eventually be locked out of the Google ecosystem.
- 015a 4y agoI'm curious to get a take on Apple's documentation for passkeys and iCloud Keychain Recovery Escrow system [1] [2] There's multiple references in this documentation to phrases like "To sign in for the first time on any new device, two pieces of information are required—the Apple ID password and a six-digit verification code" or in the no-device-recovery escrow documentation: "users must authenticate with their iCloud account and password" I can imagine a world where Apple replaces sign-in passwords with passkeys; your devices form a ring of trust which "sponsor" new devices into your end-to-end-encrypted iCloud Keychain. But I'm having a hard time imagining how zero-device escrow recovery can work without a thing-you-know password. Has Apple spoken specifically on this at all? Do they intend to follow the same route as Google and get rid of passwords entirely, and if so how are they securing zero-device iCloud Keychain recovery? Or will they probably just keep passwords around, if only for this specific use-case; and if so, what are the implications for functional user security? If I have an Apple Password I don't use for ten years, then have to use it that one time to complete zero-device recovery, many users won't remember it. [1] https://support.apple.com/en-us/HT213305 https://support.apple.com/en-us/HT213305 [2] https://support.apple.com/guide/security/escrow-security-for-icloud-keychain-sec3e341e75d/web https://support.apple.com/guide/security/escrow-security-for...
- philistine 4y agoMy presumption has been that they will force a long recovery key to be printed by you for recovery OR the enrollment of designated trusted users that can approve an account recovery. They already force you to do either of those things if you want end-to-end encryption for all content types (which they called increased data protection).
- mihaaly 4y agoI will never weld my login to a physically so fragile and unpredictably high maintenance and volatile thing as a mobile phone. It is also cumbersome for casual logins and increadibly risky for important ones. Thank you, but no. (good thing I already started to migrate away from the Google universe)
- mdswanson 4y agoIs it just me, or does every "what is a passkey" definition never actually define what passkeys are?
- eulers_secret 4y agoI’m a Linux user. I don’t have an android/iOS/macOS/Windows machine. Is there a solution? Is this being used to push Linux users off the internet? Can I just fire up emulated Android and be ok? Am I screwed? Googling indicates I am, indeed, screwed. Pretty concerned about this future.
- nmca 4y agoYubikey is supported; which has linux compatibility.
- chlorion 4y agoPasskey is an open standard and there exists FOSS clients which support it. We should try actually understanding and learning about what's going on instead of assuming that it's a Google conspiracy to kill Linux. (google contributes heavily to linux anyways?)
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- RobotToaster 4y agoDoesn't this just mean giving control of authentication to proprietary systems like google? I can't find a single FIDO level 2 (or higher) certified implementation that is open source?
- ilyt 4y agoThat kinda looks like vendor-locked equivalent of pub/privkey auth ?
- tomrod 4y agoBiometrics are not passwords. They are user IDs. I have concerns with this approach. EDIT: Looks like support will be coming to NordPass and other password managers soon - https://support.nordpass.com/hc/en-us/articles/12984678202641 https://support.nordpass.com/hc/en-us/articles/1298467820264...
- Lacerda69 4y agopasskeys wont be the end of passwords: https://www.ory.sh/overview-login-password-passkey-webauthn-totp-sso-faceid/ https://www.ory.sh/overview-login-password-passkey-webauthn-...
- 0xbadcafebee 4y agoThis is a good start, but like everything Google introduces, it's only designed to be useful to Google, and has a number of flaws: - syncs to the cloud without E2E encrypted. there's no reason any person should ever put all their private keys somewhere they can be stolen without at least a secret master password protecting them. - they're not one standard. web apps will use WebAuthN, non-web apps will use a FIDO API. Passkeys are a mix of different technologies that is more complex than needed. - they aren't interoperable with different software and devices. Currently, if you make a passkey, it can only work with whatever you used to make it. trying to use a passkey on different operating systems or apps etc requires manual workarounds, exporting/importing, etc. - different providers have different levels of support. some support sign-in, some support MFA, some support both. - the choice of only being able to use biometrics or a pin to protect the passkey store is stupid. you should be able to enter in text as well, so you can use a long and complex key to protect it, if you want. instead your options are 3 incredibly easy to crack methods. - there isn't an easy way to back up everything offline in case your devices get lost. - all this doesn't address attacks on account recovery, which is the most common way to compromise an account (nobody brute-forces passwords anymore, with the exception of giant password compromises which are used for lateral attacks against other services)
- 2OEH8eoCRo0 4y agoWhen a company rolls out something new and exciting that will improve your life, ask yourself: why are they spending money on this? Just stuffing more of our private lives into phones full of ads and tracking. Each time you unlock your phone Google makes money.
- AlexandrB 4y agoThere is a less sinister motive available - reducing customer support costs - but the default of syncing everything to the cloud does give me pause.
- dpedu 4y agoNo thanks. I trust google to a degree, but not that far.
- talkingtab 4y agoHow does google make money? By having information about users and providing that to people who want to 'target' users. So in the interest of making a 'better' user experience we now have google passkeys. Is Google making this to help users or perhaps does it provide more ability to target users. Hmmm..... You are not googles customers. Advertisers and other agent wanting to target you are google customers. Channeling someone, "just say no to google." Or "friends don't let friends use google passkeys".
- Zamicol 4y agoOn my website, I'm doing authentication via simple public key authentication using Coze. No passwords. No email. No Google. Just public key authentication with private keys in possession of the user. https://github.com/Cyphrme/Coze https://github.com/Cyphrme/Coze
- 8organicbits 4y agoI've always expected end users would struggle to manage private keys. What sort of users does your website have?
- Zamicol 3y agoSorry for the delay. I didn't want too many eyeballs on it yet. https://cyphr.me/wallet?power https://cyphr.me/wallet?power
- attah_ 4y agoGoogle: What are Passkeys? Also Google: Goes on to not explain what they are at all. That's about when i stopped taking it seriously.
- hunter2_ 4y agoCame to HN today figuring there would be a thread about this, after getting an email about it from Google themselves, riddled with things causing me to wonder if the message was spoofed: 1. "Dear User" -- other emails I've gotten from Google say "Hello" or "Hi <firstname>" or have no salutation at all. 2. The main section begins with "Passkey support will be integrated because they’re easier to use, and safer than most other forms of 2-SV." -- The plural antecedent of "they're" is merely implied (the literal plural antecedent "passkeys" isn't actually written). 3. In that same sentence, the comma before "and" is grammatically incorrect. The comma should not exist, or it should be followed by a complete sentence. The same comma rule is also violated in a later sentence: "You won’t need to enter a password to sign in to your account, or to select only a single phone to use as your built-in security key any longer." I'm not really a huge stickler for grammar, but I've seen countless "how to spot phishing" guides specifically suggesting that we look for grammatical mistakes, as they're specifically included for purposes of improving the ratio of hooked phish to eaten phish, so it follows that messages which aren't phishing really ought to use correct grammar!
- nobody9999 4y ago>I'm not really a huge stickler for grammar, but I've seen countless "how to spot phishing" guides specifically suggesting that we look for grammatical mistakes, as they're specifically included for purposes of improving the ratio of hooked phish to eaten phish, so it follows that messages which aren't phishing really ought to use correct grammar! Lily Tomlin & co. could have made this[0] for Google today, instead of for AT&T ~50 years ago. The dynamics haven't changed, just the corporations involved. And more's the pity. [0] https://vimeo.com/355556831 https://vimeo.com/355556831
- tialaramex 4y ago> I've seen countless "how to spot phishing" guides One of the things you'd see those guides mention a lot is the call to action. The bad guys want you to do something for them, otherwise they wouldn't send you email. In contrast the Google email you're complaining about says, "No action is required from you" which is my favourite type of letter from every company. Can I forget all about this and take no action? You bet I can.
- jimmar 4y agoThe paragraph in the section, "What are passkeys?" tells me that they: are new, are easier, let me use biometrics, and are resistant to attacks. But, it doesn't tell me what passkeys actually are. Compare passkeys to traditional authentication factors. What's a password? A secret word or phrase that only you know. What are biometrics? Parts of your body that can help uniquely identify you, like your fingerprint or retina. What are hardware tokens? They are physical devices that give you codes that verify that the person logging in has the device on their person. What are passkeys? Until they develop a way to explain what passkeys really are, I question how quickly they will be adopted.
- JustSomeNobody 4y agoThank you. I've been trying to figure out what they hell they are and have been unsuccessful. I thought it was just me.
- TulliusCicero 4y agoThis goes into more detail: https://developers.google.com/identity/passkeys https://developers.google.com/identity/passkeys As far as I can tell: it's a system of private keys stored on devices, in order to transmit a key you also need to unlock a device (e.g. phone) with some other method like a PIN or fingerprint/face scan. Combine those two things and it means a would-be hacker would need both the physical device as well as the local authentication for that device (PIN or biometrics).
- deleted 4y ago[deleted]
- laegooose 4y agoCan it be uses on both Android and iOS? What about desktop machines with no fingerprint sensor or faceID? What happens if user loses the only device on which passkey was enrolled?
- 4y ago
- insane_dreamer 4y agothe "end of the password" is like the "year of linux on the desktop"
- TulliusCicero 4y agoHmm, can I use these passkeys with Brave or other Chromium-based browsers?
- SheinhardtWigCo 4y agoUsers pay a subtle price for the perceived convenience of passkeys when it's time to migrate to another platform. Before, you could just sign in to your password manager on the new platform, and get a 2FA prompt the first time you sign in to any particular site (so you're manually entering one additional factor per site). With passkeys, you have to do account recovery, so you have to manually provide two factors per site. That translates to hours of cumulative extra work. It's an opportunity to increase platform stickiness, backed by a flimsy security excuse. Nobody using a password manager is getting their accounts hacked unless the vendor is breached or they have malware on their system. Passkeys don't help in either scenario. And the UX isn't materially better than the built-in password manager, though I guess that's a matter of opinion.
- organman91 4y agoIt looks like this is a wrapper around public/private keys stored on a device: https://security.googleblog.com/2023/05/so-long-passwords-thanks-for-all-phish.html https://security.googleblog.com/2023/05/so-long-passwords-th...
- CatWChainsaw 4y agoThe technology of passwords has been around for millennia, never perfect, not terrible enough to throw out wholesale. As I said somewhere else, the democracy of authentication, the best of several imperfect options. Certainly I'm not securing anything of mine behind my phone (can be broken) or my face (can also be broken) on a proprietary system under Google's fickle control, when my brain is less likely to be broken (and if it's not, I'll have much bigger problems to worry about than getting into my accounts).
- voytec 4y agoComing soon to a device new you, from the authors of no E2E encryption on Authenticator backups! [1] [1] https://news.ycombinator.com/item?id=35708869 https://news.ycombinator.com/item?id=35708869 [1] https://news.ycombinator.com/item?id=35720460 https://news.ycombinator.com/item?id=35720460
- kroeckx 4y agoIs a passkey a software implementation of a FIDO key? Where the implementation could use something like the TPM to protect the key.
- mdtancsa 4y agoIt seems awfully trivial but in the context of a positive security announcement g.co/passkeys (my gut says, "what is this scam? I am not clicking on that") https://myaccount.google.com/signinoptions/passkeys https://myaccount.google.com/signinoptions/passkeys (my gut says, "interesting, let me take a look")
- Phemist 4y agoArgh. Passwords are amazing. I loathe many of the attempts at replacing them simply because the _average_ user has proven to be unable to manage them. The three factors of authentication are a thing because they all protect against somewhat orthogonal threat vectors. Possession "have" is nice because it binds the authentication to a single thing in the real world (as opposed to some digital thing that can be copied endlessly). Biometrics, if nice, is something that is relatively unique and always carried with you (mostly identification), and bind the factor to a person, secrets like passwords are nice because they essentially bind the factor to the intent, in that a user displays their secret behaviour (of which passwords are one) as opposed to not displaying the behaviour. Articles that solely focus on the downsides of passwords, often neglect downsides of the other factor types. What are ways the strong personal binding of the "are" factor can be abused if there is no intent? FaceID/TouchID on sleeping or otherwise inattentive persons is a prime one. All factor-types can work in ways that complement eachother. Removing or at least weakening passwords is not a good way forward, we need to work on fusing all the factor-types jnto a single strong 3-factor auth
- JohnFen 4y ago> we need to work on fusing all the factor-types into a single strong 3-factor auth Would this not make logging into things three times more painful? Even just using 2FA is a pain right now.
- Phemist 4y agoThis is another hot take, the word factor is overloaded (by marketing people) to be really confusing. The three factors of auth are categories / types. TOTP, password-entry into a form, biometric presentation, etc are _measures_. Sometimes the first measure is not sufficient, because it only implements one factor-type (e.g. the secret knowledge password), and a second measure that like TOTP is necessary which proves possession of something to a degree. The time between proving one measure and then the next 2"F"A measure allows many shenanigans (e.g. social engineering to get me to send a TOTP code to my down-on-his-luck "son"). What I am professing is a focus on measures where proof of all three factor types happens at the same time. PIN codes as entered to unlock a private key on a smartcard, which is then used to sign some other thing, would be one example of a 2-factor measure. Another is FaceID/TouchID (on-device matching). But 3-factor measures are not impossible - e.g., take also the keystroke dynamics into account of a password being entered on a specific device, apple could implement "KeystrokeID". Other options can exist, it just takes some creativity to think of how a secret behaviour can be encoded into a biometric modality that is then only understood by a specific device..
- jesterpm 4y agoI don't use my google account for much anymore, but I love the idea. I tried very hard to use it and... it didn't work. I went to my google account and clicked "Create a passkey", but apparent my "device doesn't support creating passkeys" (Linux, Firefox). The page said my Pixel 2 has an automatically created passkey, so maybe I could experience the "use another device to sign in" flow. Opened a private window and my only option was a password (but there was a feedback prompt asking why I still wanted to use a password). I tried again with Firefox on Android, but the "Create a passkey" button doesn't even appear. Same story with Chrome on Android. Is it just me, or does the future look a lot like Internet Explorer in the early 2000s?
- rcarmo 4y agoI've yet to figure out how passkeys can be useful for someone who switches between multiple devices (and platforms) throughout the day, and who wants to retain control over where tokens are stored. I have switched as many of my MFA credentials as possible to TOTP and have avoided Yubikeys because I don't want to be tied to a single piece of hardware that can be easily lost, or to an identity provided that may decide to lock me out...
- NikolaNovak 4y agoIgnorant question: Are Passkeys, at some level of abstraction, permanently replacing "something you know" (password) with "something you have"? If I am in some kind of calamity (dropped my phone, got robbed, etc), and I come to a friendly person's house, it sounds to me like I simply would not be able to login to potentially critical services, no matter how much I know, because I don't have anything (the device that passkeys are tied to / on). Is that true? And... am I the only person completely dreading this system? I don't live on my one and only phone; I have two phones, 3-4 tablets, 4-5 computers I use regularly. Of various operating systems, browsers, manufacturers, etc. I can create a password of arbitrary complexity and security and comfortably use all my devices as well as any new device that comes my way. Passkeys sound... like a nightmare? (they also sound AMAZING to my wife and family... woohoo no passwords, I just have to use my phone... until they INEVITABLY lose or break their phone... and then they'll come to me and I have no idea what to tell them anymore -- all your passkeys were on your device and now they're gone forever because Google & Apple decided it was better for you, and you did not follow obscure methods I frankly cannot help or explain to you to maybe possibly back them up, one day, when method exists, to some other device)
- dcow 4y agoI like to explain it like this: If you use a password manager today, then you're already essentially using something you have, because you need to be in possession of your login database to retrieve passwords, and nobody can remember that in their head. Passkeys is a formalization of the idea that you should be using a password manager where all the passwords are random uncrackable 32 character strings, and if we add this constraint then we can crazy secure things like employ asymmetric crypto to prevent phishing and MITM attacks, so woO!. You are right to be concerned about the whole device thing though. Apple addresses this by requiring that you use/enable iCloud keychain in order to use passkeys. The generalized solution to this is allowing 3rd parties to be your passkey provider, so that you can choose how your passkeys are stored (cloud synced vs device bound) and e.g. whether you want an implementation where you can unlock them with one strong something you know, something you are, something your have, or any combination thereof, the only limit being the features/options the different 3rd party products will offer, depending on their target market, etc.
- account-5 4y agoNope, passwords stay until passkeys aren't tied to a device that can be lost, stolen, or broken. Or you need multiple devices to avoid that. And they are offline and not controlled by multinational corps only interested in monitoring everything you do for profit.
- bobsoap 4y agoOk, Google. I'll bite. So you send me an email today titled "[Update] Google passkey support will replace your built-in security key starting May 3, 2023". It was in my spam folder, but I digress. This "update" kindly informs me that "Passkey support will be integrated because they're easier to use" [sic], that it's safer than most other forms of 2-SV, that this new method will work on any devices that have registered passkeys, which includes all phones on which I'm signed in, that I'll be able to sign in to my Google account with just a passkey, that no action is required from me to do this, and that you're here to help. Yes, Google, I'd like some help. For starters, I'd like to know: - What do you mean by "built-in security key"? Built-in suggests hardware, so my phone presumably has a hardware security chip and now passkey is a new type of hardware chip for authentication? - What's 2-SV? Two Sievert? Dos El Salvador? Double Support Vector? Second Silicon Valley? - What the heck is a passkey? Luckily, you provide a link to your HC article [1], which I click on. It's titled "Sign in with a passkey instead of a password". It helpfully informs me that with a passkey, I can sign in to my Google account with my fingerprint/face scan/device screen lock like a PIN. There's a bunch of other valuable information in that article, like how it won't work in Firefox, won't work in incognito mode, that Bluetooth must be enabled, and that anyone who manages to unlock my device gets full access to my account. Needless to say, sounds totally awesome, I'm sold!!1 What the heck is a passkey? Is it like the thing that sometimes uses my Android phone as a 2FA device to sign into Google properties, just... somehow different? What's the difference, except that I now need to enable Bluetooth and can't use it in Firefox? How is it more secure than [something I know + something I own] if it removes [something I know] from the equation and only leaves me with one of the two factors? How is it more secure than Dos El Salvador? Who the heck wrote this email? [1] https://support.google.com/accounts/answer/13548313 https://support.google.com/accounts/answer/13548313
- ssss11 4y agoIf I choose the screen lock PIN example (instead of face scan or finger print) why/how is that more secure and less resistant to attack than a password? It’s a 4 digit number. What am I missing behind the scenes that makes it more secure?
- hanniabu 4y agoSign in with ethereum is my preference https://login.xyz/ https://login.xyz/
- rgrmrts 4y agoMy understanding of passkeys was that they replace passwords, but a few places where I’ve seen them implemented just use passkeys as a second factor, NOT a replacement for passwords themselves. Can anyone who knows more about passkeys explain why this is the case? Are service providers just misusing passkeys as the second factor, or do I misunderstand passkeys?
- alkonaut 4y agoDid anyone else get an email from Google about this, with a link I’m supposed to click on iOS, but which is broken? Did Google really email all their iOS+Google users a broken link?
- JoshTko 4y agoOne weakness with passkeys is that a person can't login to an account with just information that they know. I.e. they need a authorised device. Given that devices can be lost, it seems that folks that only own one device should not use Passkeys. Most passkey users should probably have a minimum of three biometric enabled - authorized personal devices if they want to use passkeys. This might be the biggest roadblock to adoption as few have this many personal devices.
- shortcake27 4y agoThe goal from all vendors is absolutely to have passkeys backed up to the cloud. In fact, passkeys on iOS required iCloud Keychain to be enabled. Then the only issue is reauthorisation with the vendor when the only trusted device is lost. It would be surprising if vendors didn’t cater for this scenario.
- jdeibele 4y agoI've lost a lot of confidence in Apple's keychain. I had been using iCloud Keychain and backing up username and password into BitWarden. I say "had been" because 189 lines of garbage entries are in iCloud Keychain and I can't get them out. They look like this: Title,URL,Username,Password,Notes,OTPAuth www.amazon.com (MEoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECJeL6XzO81KJBCA02+DHVDASQ5Y3hOVrhGjCxV9Mv9qSEOc7uod7iKS3Rw==),https://www.amazon.com/,MEoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECJeL6XzO81KJBCA02+DHVDASQ5Y3hOVrhGjCxV9Mv9qSEOc7uod7iKS3Rw==,MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECJW/8Qf4Ax9TBBDIv2FaLx8/To2omiNn/or0 https://www.amazon.com/,MEoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZI...,, (repeat for various sites 188 times) I've tried deleting them multiple times but they always come back. I've filed Feedback with Apple but no acknowledgement of the problem. There's no hint as to whether the problem is with one of my devices or with iCloud. I've switched over to BitWarden entirely. At some point, I guess I try deleting the keychain and starting over but I really am concerned about using something that allows an error like this.
- uni_baconcat 4y agoPasskey is convenient and safer than password, but all of that is based on the trust of 'trusted device'.
- Am4TIfIsER0ppos 4y agofuck off and bring back smtp access!
- danShumway 4y agoThey still haven't solved the portability problem, there still is no way to use a Passkey without interacting with a proprietary device or hardware, it's still pretty transparently going to enable vendor lock-in. This technology is harmful. "But it's early days, portability is coming." Google/Microsoft have been saying this for ages, and it hasn't happened yet. And there's no effort being made to mandate portability as part of the spec, so even if the companies ever actually get around to allowing cross-ecosystem sharing, there are still going to be implementations that don't support portability. And honestly at this point I feel like it is an "if" not a when because Google and Microsoft and Apple are not talking about this being early days, they are encouraging people to switch over right now. So if you launch a feature and you encourage people to start using it for everyday logins, and it doesn't support cross-ecosystem export/import, then it doesn't seem like that's a priority or a blocking issue. "But 1Password will support this" No, 1Password is looking to support cross-device syncing, it's not allowing you to move out of the 1Password ecosystem. It's just tying to the 1Password account instead of the hardware. "But cross-ecosystem syncing would enable phishing" We crossed that bridge. If you can sync passkeys between devices (and every major player is going to allow that), then there are phishing risks. iCloud accounts can be hacked. Your 1Password account can be compromised. It's not for the sake of security that Apple allows syncing keys across devices but not to other ecosystems. "Just use a Yubikey" That's still proprietary hardware and the recovery process that people advocate for with Yubikeys is ridiculous and unworkable. I'm supposed to have 2 keys that I keep in sync and store in different places. I have enough trouble synchronizing Org-mode files between computers, that is not a feasible way to manage account logins. I refuse to get excited for or advocate for a technology that at this point is just transparently about vendor lock-in, no matter how many times that advocates say it's not. Every time I look into this I wonder if something has changed, but last I checked FIDO alliance is not looking to standardize portability, they're just leaving it up to individual companies. Well, what that means is that maybe if you're lucky you'll be able to sync keys from Microsoft to Apple and vice-versa. You won't be able to sync those keys to a Linux computer (Chrome's implementation of login doesn't even work on Linux without a hardware key, you literally can't use that computer to log-in without a separate non-Linux device). We should reject this. Passwords have real problems and a key-based authentication system would be a major improvement. It stinks that it's being run this way. And it stinks that advocates for Passkey are trying to argue that it's Open when there's not a single non-proprietary implementation on the entire market. It honestly feels deceptive to me, I have no trust in the FIDO alliance right now. There's been basically no visible progress on this, and every time the issue gets raised, somebody shows up to say that we just need to wait longer. Well... now it's launching. And surprise, we need to wait longer.
- jiggawatts 4y agoI keep hearing a lot of talk about Passkeys, but I haven't yet seen any web site, service, platform, or cloud where I could actually use one. Has anyone used these in the field for a major, popular site or product? What was it? More importantly: What if I have a Windows laptop and an iPhone? Can I transfer a Passkey from my "only Apple device" to something else as a backup, or will these be locked to one vendor?
- guenthert 4y agoWhat about 3rd party applications, say MUAs like mutt or Evolution? Will I be able to generate a passkey and store it in the desk-top's ssh-agent for the MUA to retrieve on demand?
- nytesky 4y agoI tried added passkeys to my Google account, then tried to login thru incognito browser. It gave me the option for logging in with a passkey — and then showed me a QR code to scan???? Where did I go so wrong??
- csomar 4y agoI understand crypto/web3 are hated because of all the scams and NFTs out there. However, I worked on a web3 login implementation and I think it’s the best login/account experience out there. Basically, your private key is your password. You can use your phone, a browser extension or a hardware wallet (kind of the equivalent of a YubiKey). It’s a pretty straightforward experience and it keeps the full ownership of the credentials to the user.
- snowwrestler 4y agoThis is how passkeys work
- Rufbdbskrufb473 4y agoExcept you can no longer back up your private key, so you must trust a 3rd party to restore access when you lose the only allowed copy.
- csomar 4y agoI’m not familiar with passkeys. Can you back it up as a bunch of words? Does it require a third-party thing or the implementation is fully independent.
- mattdesl 4y agoIt seems passkeys mostly operate in the cloud, like replication across all iCloud connected devices? This seems like a major point of vulnerability for the average user. Private key infra in crypto/web3 tends to promote best practice as offline, paper wallet, airgapped devices, etc.
- hnburnsy 4y agoFrom the Google Developer FAQ... https://developers.google.com/identity/passkeys/faq https://developers.google.com/identity/passkeys/faq >Can I move synchronized passkeys from one platform provider to another? >Each device / platform may offer different experiences and controls. But a user can always register a second credential with a site and remove the first, effectively “moving” from one to the other.
- fortran77 4y agoHow is my 90 year old mother supposed to figure this out? I can get her to use log passwords that she writes down.
- rglover 4y agoI don't understand the hate for passwords. I want to keep my security in my head for as long as humanly possible. There was a whole movie plot about this [1]. [1] https://youtu.be/JrBdYmStZJ4?t=238 https://youtu.be/JrBdYmStZJ4?t=238
- topmax 4y agoBasically, this thing need a complete ecosystem, any broke in link will lead to lose efficacy.
- WirelessGigabit 4y agoI believe to this date passkeys are not exportable. As such I am stuck either using Apple or Android. I cannot move between the 2.
- diego_sandoval 4y agoSo, what I take from this announcement and the linked article [1], is that: This is a closed system, with no public standard protocol, where you will have to use the stock closed-source operating system that comes with your phone, and you will need to have your cellphone with you every time you need to login, even if you want to login on a different device, and presumably, that phone also needs to have an Internet connection. Maybe I misunderstood something, but I would never voluntarily use such an abomination. [1] https://blog.google/technology/safety-security/one-step-closer-to-a-passwordless-future/ https://blog.google/technology/safety-security/one-step-clos...
- thefounder 4y ago"Passkeys aren’t allowed on this account. Contact your admin for help" Being admin on google apps doesnt help
- vinay_ys 4y agoPasskeys as implemented by Apple/Google has serious limitations – your credentials are locked into their platform and tied to their online account (iCloud account or Google account). They won't let you use your phone as a FIDO2 authenticator via 3rdparty apps (like 1Password or Bitwarden). Your credentials are only as secure and reliable as their online account services are, and they are subject all the risks of state/corp spying, forced logins at cross-border transits etc. The dangers of this are quite clear – if you get banned or locked out from your iCloud account or Google account (this is known to happen – with no appeals process), then you lose access to all your passkeys immediately. If you are forced to reveal your Google or iCloud account credentials under threat, you have effectively handed over all your credentials. There is no way to disable cloud syncing of your credentials. By not allowing 3rdparty apps to speak BLE/NFC CTAP2 protocol on their phones, they are effectively crippling the phone you bought and paid for to be tied to their online platform more deeply. They have turned a supposedly open standard that is FIDO2 authenticator (as described in the white paper) into a platform-lockin product called Passkey. One excuse for this could be that there are risks to giving 3rdparty apps permission to speak raw BLE/NFC. But that doesn't need to be the case – CTAP2 authenticator protocol could be a platform component and it could be its own specific permission that can be given to apps that qualify it (there are special privileged api permissions like that today in platform already).
- codery 4y agoI wish world (Apple, Google, Microsoft etc.) had implemented SQRL instead of PassKeys :( SQRL: https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm
- jacquesm 4y agoThis is just a way to tie your identity more closely to your account, it doesn't make anything more or less secure. Every big silo is trying to do this constantly and once you recognize the pattern you'll see it everywhere. Never mind the inconvenience to the users, all that matters is that you are known to the system wherever you are and on whatever device you are using so that your profile can be closely matched to your various interests and intents the better to sell advertising (or your data, depending on the operator). My recommendation: get a yubikey that you wear on your keyring, it's not as cheap as a password but it adds another layer of security without an even closer tie to you as a person, you can usually associate more than one yubikey with an account which gives you a way to diffuse ownership of the account without tying it to a particular computer or phone. And stay away from biometrics if you can.
- GivinStatic 4y agoMy thoughts exactly. In the post linked and in the post explaining how passkey works they mention that none of biometric data is sent to google. The catch? More precise data about your devices and subsequently about you.
- alpos 3y agoJust here to note that there are several huge problems with this approach from an actual security standpoint: First is that this changes from 2-factor authentication (something you have plus something you know) to single-factor (just something you have). Also be sure to notice in the article that they have changed their term there to 2-STEP authentication, not 2-FACTOR authentication, these are not the same thing, and they know that. It's important that you know the difference too if you want any kind of real security. If you use passkeys plus an authentication code app, then you have 2-steps (for whatever that's worth) but not 2-factors since they are both just a piece of code on your device, if they are both on the same device, that's even less secure since they can both be compromised at the same time, and in practice they will be. Second is that the now single factor authenticator is strictly worse than a password because it is something that can be taken away from you and manipulated without your permission. Third is that the keys are not private since the passkey provider is storing them for you and/or copying them around. This means they can be spied on, stolen, or demanded by the government, all without you even knowing someone else got access to your stuff. The last glaring issue I can see for the time being is that it relies on a simple, easily cracked unlock pin, or worse still fingerprint/facial recognition bio-metrics as the only way to keep someone, other than Google, out. One might be tempted to think facial recognition or fingerprints are pretty good security but it's already been demonstrated that people can break those mechanisms quickly and the cops can and will use your fingerprint and/or mug shot to unlock your phone if it's locked by biometrics only. They are not allowed to force you to give your real password, but the courts do allow them to use any means they like to break into your phone. Even if they damage it in the process, they just have to pay you back for it, they still get to take your data and use it against you. Just some things to keep in mind before anyone gets too excited about this "new" invention. There's a reason we still have passwords even though we've had Smart ID Cards (such as DoD's CAC system https://www.cac.mil/ https://www.cac.mil/) and other device driven access controls for decades now.
- UncleMeat 3y agoI completely disagree. Even if you are concerned about evil maids (which are comparatively very rare), it is not the case that passkeys are "strictly worse" than a password. The core advantage is that they cannot be phished. And not only does phishing exist, it is way more common than people stealing your hardware used to authenticate you with a passkey.
- gnufx 3y agoRegarding the statements that you need a Yubikey (for the FIDO part of passkey, given application support?) on GNU/Linux, at least Solo 2, Nitrokey 3, and Onlykey hardware keys have free firmware. I can't vouch for them, but maybe also see https://github.com/psanford/tpm-fido https://github.com/psanford/tpm-fido and https://github.com/bulwarkid/virtual-fido https://github.com/bulwarkid/virtual-fido
- madjam002 3y agoStill flawed seeing as you can't disable Google Prompts (that I know of) which means any security key 2FA or Passkeys that you've set up can be bypassed if your phone is stolen as someone can simply click a prompt in the Gmail app. I wish they gave the option to disable this.
- neop1x 3y agoSo, if Google suspends my account, I will lose access to everything indefinitely? No, thank you! I am happy with my passwords (Bitwarden + Aegis).
- knaik94 3y agoThere's no meaningful benefit of this over a password and 2FA authentication for users who are already proactive about security. I also doubt that passkeys will be protected by the fifth amendment the way passwords are, based on the "key vs combination" argument. While I trust Google password manager to help me remember passwords, I don't trust Google or any company to manage them for me. At their core, passkeys are a easy and nice way to move from passwords to public private key cryptography. And hardware based authentication does allow more security. And by leveraging the hardware-backed keystore and security enclave, you can use your phone the way FIDO keys are already used. But there aren't clear benefits over 2FA and a password. There are many reasons why I will wait as long as possible, maybe indefinitely before I start using passkeys. The idea of this being tied to Google or any other major company for my logins is not okay. There are many cases of people being locked out of Google accounts without the ability to appeal. With current 2factor, you can control the secrets yourself if you choose to. While it's true that you can't be phished into sharing your passkey as easily, you also lose a lot of convience and flexibility in login management. And it makes login sharing or multi-account management very inconvenient and difficult. I was hopeful with 2FA rolled out that my accounts would be more secure, but most companies give you very little over which methods of 2FA are allowed or enabled. I don't want to be forced to enroll a phone number just to enable TOTP 2FA. I want to be able to choose between TOTP or HOTP for my accounts. I don't want to be forced to use a 2FA app that doesn't allow me to export and manage the secrets myself. In some ways FIDO keys solve some of those issues, but the hardware security aspect of it contradicts giving the end user the choice to self manage. https://www.concordlawschool.edu/blog/constitutional-law/fifth-amendment-biometrics/ https://www.concordlawschool.edu/blog/constitutional-law/fif...
- blooms112 3y ago[dead]
- blooms112 3y ago[dead]
- spicysugar1 3y ago[dead]
- spicysugar1 3y ago[dead]
- galaxy12 3y ago[dead]
- galaxy12 3y ago[dead]
- gypsysoul1 3y ago[dead]
- gypsysoul1 3y ago[dead]
- julesontour45 3y ago[dead]
- julesontour45 3y ago[dead]
- pinchofsalt2 3y ago[dead]
- pinchofsalt2 3y ago[dead]
- reading1234 3y ago[dead]
- angelhearts1 3y ago[dead]
- angelhearts1 3y ago[dead]
- lustforlife1 3y ago[dead]
- lustforlife1 3y ago[dead]
- weworewhat9 3y ago[dead]
- weworewhat9 3y ago[dead]
- smashfizzle1 3y ago[dead]
- smashfizzle1 3y ago[dead]
- livincool11 3y ago[dead]
- livincool11 3y ago[dead]
- selfcare4yu1 3y ago[dead]
- selfcare4yu1 3y ago[dead]
- terthanthesun1 3y ago[dead]
- genes123 3y ago[dead]
- genes123 3y ago[dead]
- floufrouu121 3y ago[dead]
- floufrouu121 3y ago[dead]
- morelight11 3y ago[dead]
- morelight11 3y ago[dead]
- reading1234 3y ago[dead]
- livincool134 3y ago[dead]
- livincool134 3y ago[dead]
- pistache12 3y ago[dead]
- pistache12 3y ago[dead]
- smashfizzle12 3y ago[dead]
- smashfizzle12 3y ago[dead]
- terthanthesun1 3y ago[dead]
- thatnerdy12 3y ago[dead]
- thatnerdy12 3y ago[dead]
- angelhearts9 3y ago[dead]
- angelhearts9 3y ago[dead]
- smashfizzle7 3y ago[dead]
- smashfizzle7 3y ago[dead]
- monsoon11 3y ago[dead]
- monsoon11 3y ago[dead]
- floufrouu11 3y ago[dead]
- floufrouu11 3y ago[dead]
- morelight19 3y ago[dead]
- morelight19 3y ago[dead]
- sharinggenes1 3y ago[dead]
- sharinggenes1 3y ago[dead]
- indigosparkle1 3y ago[dead]
- indigosparkle1 3y ago[dead]
- morelight18 3y ago[dead]
- morelight18 3y ago[dead]
- advocates19 3y ago[dead]
- advocates19 3y ago[dead]
- selfcare111 3y ago[dead]
- selfcare111 3y ago[dead]
- yourblanks17 3y ago[dead]
- yourblanks17 3y ago[dead]
- butterflyeffec 3y ago[dead]
- butterflyeffec 3y ago[dead]
- lifebutterfly 3y ago[dead]
- lifebutterfly 3y ago[dead]
- gobblers1 3y ago[dead]
- gobblers1 3y ago[dead]
- livincool87 3y ago[dead]
- livincool87 3y ago[dead]
- selfcare11 3y ago[dead]
- selfcare11 3y ago[dead]
- reading87 3y ago[dead]
- reading87 3y ago[dead]
- flightsnot81 3y ago[dead]
- flightsnot81 3y ago[dead]
- doodles675 3y ago[dead]
- doodles675 3y ago[dead]
- indigosparkle7 3y ago[dead]
- indigosparkle7 3y ago[dead]
- morelight876 3y ago[dead]
- morelight876 3y ago[dead]
- monsoon654 3y ago[dead]
- monsoon654 3y ago[dead]
- indigosparkle6 3y ago[dead]
- indigosparkle6 3y ago[dead]
- fabulous13 3y ago[dead]
- fabulous13 3y ago[dead]
- champagne7 3y ago[dead]
- champagne7 3y ago[dead]
- flightsnot45 3y ago[dead]
- flightsnot45 3y ago[dead]
- styleslover123 3y ago[dead]
- styleslover123 3y ago[dead]
- isonfire11 3y ago[dead]
- isonfire11 3y ago[dead]
- shop13213 3y ago[dead]
- shop13213 3y ago[dead]
- aholicdiva 3y ago[dead]
- aholicdiva 3y ago[dead]
- workofgod132 3y ago[dead]
- workofgod132 3y ago[dead]
- pink1321 3y ago[dead]
- pink1321 3y ago[dead]
- lusttforlife567 3y ago[dead]
- lusttforlife567 3y ago[dead]
- thatsassy127 3y ago[dead]
- thatsassy127 3y ago[dead]
- lwithnojob65 3y ago[dead]
- lwithnojob65 3y ago[dead]
- inkandpaper1 3y ago[dead]
- inkandpaper1 3y ago[dead]
- withnojob0 3y ago[dead]
- withnojob0 3y ago[dead]
- kong45 3y ago[dead]
- kong45 3y ago[dead]
- gaming56 3y ago[dead]
- gaming56 3y ago[dead]
- goddess09 3y ago[dead]
- goddess09 3y ago[dead]
- gypsy645 3y ago[dead]
- gypsy645 3y ago[dead]
- wanderlust56 3y ago[dead]
- wanderlust56 3y ago[dead]
- chicnext673 3y ago[dead]
- chicnext673 3y ago[dead]
- door7544 3y ago[dead]
- door7544 3y ago[dead]
- avocados564 3y ago[dead]
- avocados564 3y ago[dead]
- foodie564 3y ago[dead]
- foodie564 3y ago[dead]
- lyjules464 3y ago[dead]
- lyjules464 3y ago[dead]
- nitch65854 3y ago[dead]
- nitch65854 3y ago[dead]
- canyon754 3y ago[dead]
- prada574 3y ago[dead]
- prada574 3y ago[dead]
- betches634 3y ago[dead]
- betches634 3y ago[dead]
- diet7865 3y ago[dead]
- diet7865 3y ago[dead]
- betch8975 3y ago[dead]
- betch8975 3y ago[dead]
- velvet6755 3y ago[dead]
- velvet6755 3y ago[dead]
- canyon754 3y ago[dead]
- collective765 3y ago[dead]
- collective765 3y ago[dead]
- max645 3y ago[dead]
- max645 3y ago[dead]
- max645 3y ago[dead]
- max645 3y ago[dead]
- max645 3y ago[dead]
- sporn656 3y ago[dead]
- sporn656 3y ago[dead]
- wolfcub7865 3y ago[dead]
- wolfcub7865 3y ago[dead]
- poemsporn75 3y ago[dead]
- poemsporn75 3y ago[dead]
- mystique5784 3y ago[dead]
- mystique5784 3y ago[dead]
- justonemore65 3y ago[dead]
- justonemore65 3y ago[dead]
- able7574 3y ago[dead]
- able7574 3y ago[dead]
- creature63 3y ago[dead]
- creature63 3y ago[dead]
- spicysugar54 3y ago[dead]
- spicysugar54 3y ago[dead]
- gypsysoul65 3y ago[dead]
- gypsysoul65 3y ago[dead]
- lustforlife451 3y ago[dead]
- lustforlife451 3y ago[dead]
- wine5433 3y ago[dead]
- wine5433 3y ago[dead]
- captures432 3y ago[dead]
- captures432 3y ago[dead]
- whatsthetea54 3y ago[dead]
- whatsthetea54 3y ago[dead]
- justdogs573 3y ago[dead]
- justdogs573 3y ago[dead]
- ssense74 3y ago[dead]
- ssense74 3y ago[dead]
- gyourstory35 3y ago[dead]
- gyourstory35 3y ago[dead]
- angelhearts45 3y ago[dead]
- angelhearts45 3y ago[dead]
- smashfizzle754 3y ago[dead]
- smashfizzle754 3y ago[dead]
- thelight453 3y ago[dead]
- thelight453 3y ago[dead]
- curioussoul46 3y ago[dead]
- curioussoul46 3y ago[dead]
- LoverKiddo12 3y ago[dead]
- LoverKiddo12 3y ago[dead]
- MeshFresh 3y ago[dead]
- MeshFresh 3y ago[dead]
- SweetMelody4444 3y ago[dead]
- SweetMelody4444 3y ago[dead]
- BadKarma234 3y ago[dead]
- BadKarma234 3y ago[dead]
- averagestudent3 3y ago[dead]
- averagestudent3 3y ago[dead]
- YellowSnowman 3y ago[dead]
- YellowSnowman 3y ago[dead]
- oprahwindfury 3y ago[dead]
- oprahwindfury 3y ago[dead]
- OP_rah 3y ago[dead]
- OP_rah 3y ago[dead]
- HeartTicker 3y ago[dead]
- HeartTicker 3y ago[dead]
- YESIMFUNNY 3y ago[dead]
- YESIMFUNNY 3y ago[dead]