[HN Gopher] Bringing passkeys to Android and Chrome
___________________________________________________________________
Bringing passkeys to Android and Chrome
Author : Heavywater
Score : 173 points
Date : 2022-10-12 15:20 UTC (7 hours ago)
(HTM) web link (android-developers.googleblog.com)
(TXT) w3m dump (android-developers.googleblog.com)
| cglong wrote:
| People are raising really good points here, but I do find it
| interesting how negatively this news is being received vs. when
| Apple said the same thing:
| https://news.ycombinator.com/item?id=31643917
| Someone1234 wrote:
| The second most popular top level comment chain is:
|
| > Unless I can back it up and import it into a new device from
| a competitor, then there is no way I am going to use this
| unless forced. I do not trust one company anymore.
|
| Which is the same sentiment as this thread. The first comment
| was just talking about the open standard of Apple's
| implementation and weakness of 2FA loss/recovery.
|
| https://news.ycombinator.com/item?id=31644190
| throw10920 wrote:
| Yup - GP made the mistake of treating HN as a single person
| with a coherent opinion. It's not, and it's _extremely_
| tiring and intellectually uninteresting to repeatedly see
| people doing that.
| pastage wrote:
| No. While I have tried to counter these group think posts
| you talk about, I only find them interesting because I
| think it is human nature to do it. I know I do it all the
| time.
| woojoo666 wrote:
| Your GP did not treat HN as a single person, they are
| simply pointing out population trends. And these trends are
| important when analyzing the dynamics of a democratic
| (upvote-based) content platform
| glenstein wrote:
| I agree, but with the following caveat. Sometimes hot takes
| inspire reflexive reactions from the crowd, reactions that
| aren't coming from a place of deeply well thought out
| reasons.
|
| So if you get a mob of people all reacting the same way to
| something, who, upon examination, have arrived at their
| conclusion for a smattering of contradictory and
| inconsistent reasons, it can be a helpful point of
| information for diagnosing the irrational mob response.
|
| Granted it's not always the case, people get to similar
| beliefs through different reasons.
|
| But these are two phenomena that exist side by side and
| there are times when it's necessary and helpful to be able
| to diagnose the first.
| notyourday wrote:
| > I do not trust one company anymore.
|
| Especially when that company is Google.
| [deleted]
| chlorion wrote:
| Yeah Google is more evil than all of those other totally
| non-evil companies that act in your best interests at all
| times. It's not like other companies have the same
| incentive to profit from you!
|
| You believing $company is not as bad as Google definitely
| has nothing to do with marketing!
| pGuitar wrote:
| Apple isn't any better then Google... they are just better at
| hiding it.
| quadrifoliate wrote:
| It's not particularly surprising. Apple has a much better
| reputation at customer service than Google does - they have
| actual stores you can walk into.
|
| Now I'm not sure whether they can help you unlock your Apple ID
| if you prove to them that you're the owner of the account, but
| I can at least visualize Apple having the scale to do that.
|
| Google on the other hand has a _horrendous_ reputation for
| locking out people out of their accounts totally and
| permanently. _Of course_ everyone has concerns about handing
| all your account login responsibilities to a company with such
| terrible customer service.
| linsomniac wrote:
| Apple, on the other hand, has terrible problems with working
| with others that google does not.
|
| Apple will happily tell you that if you want grandma to have
| a whatever color text bubble, you should buy her an iPhone,
| to name a recent example, rather than adopt the standard
| everyone else is using. I bought a Macbook last holiday
| season and couldn't even set it up until my wife set up her
| iPhone on my account to activate the laptop. I bought my wife
| a iWatch last week and briefly thought of getting myself one
| but you can't use it without an iPhone (they have a "kids"
| feature where a parent can activate it but it basically has
| no smarts at that point AFAIK).
|
| So, for making an authentication standard, I'd trust Google
| over Apple.
| duskwuff wrote:
| > I bought a Macbook last holiday season and couldn't even
| set it up until my wife set up her iPhone on my account...
|
| I have no idea what you mean by this. You do not need, and
| have never needed, to own an iPhone to use an Apple
| computer.
|
| > I bought my wife a iWatch last week and briefly thought
| of getting myself one but you can't use it without an
| iPhone...
|
| This, on the other hand, makes a little more sense. The
| Apple Watch is designed as a companion device to an iPhone.
| Much of its functionality relies upon the phone (e.g.
| displaying notifications from the phone, installing watch
| apps which pair with corresponding phone apps) -- it can't
| do much on its own.
| bfung wrote:
| W/o the phone, the watch is a... watch.
|
| If pre-installed and configure, it's still convenient for
| things like wallet/Apple Pay, esp when I do dumb stuff
| like forget my wallet and phone at home and need to pay
| for things.
| jayd16 wrote:
| What about all those ads for the cell iWatches that boast
| leaving the phone behind?
| colejohnson66 wrote:
| The Apple Watch is designed to be tethered to the phone,
| even if just for configuration.
|
| If you want to go on a hike while leaving your
| (distracting) phone behind, you can. Just don't expect
| 911 unless you have the GPS+cellular version.
| idle_zealot wrote:
| You need to have an iPhone in order to leave it behind.
| duskwuff wrote:
| The cellular version of the Apple Watch can perform a
| limited set of tasks -- like making phone calls,
| sending/receiving text messages, and playing music --
| without a phone present. It still requires a phone for
| full functionality, and for setup.
| politelemon wrote:
| > but I can at least visualize Apple having the scale to do
| that.
|
| > Google on the other hand has a horrendous reputation for
|
| Neither are true nor false but definitely exaggerations. All
| you're doing is displaying personal biases by providing them
| with benefit-of-the-doubts. They too have a reputation for
| locking people out, and are well known for turning data over,
| but one that HN in gernal prefers to ignore.
| notyourday wrote:
| > Neither are true nor false but definitely exaggerations.
|
| Google does not kill services. That does not happen. Google
| definitely does not deplatform people killing all their
| accounts and all their access. That also does not happen.
| smoldesu wrote:
| Apple absolutely did not abandon the Xserve platform
| after promising a professional and modern Unix
| experience. Google is definitely the only one with a
| penchant for mercy-killing unsuccessful products.
| vangelis wrote:
| Google isn't killing the horse with a broken leg. It's
| killing anything less than the triple crown winner.
| smoldesu wrote:
| If your horse cost $150 million/year, you'd probably be
| itching to kill it too.
| ggm wrote:
| Missing /s
| TheNewsIsHere wrote:
| At the risk of being pedantic, no. Apple Stores aren't able
| or empowered to provide Apple ID support beyond what the
| public website based recovery workflows provide. I am sure
| someone will note that someone at an Apple Store has helped
| them reset an Apple ID password. What I mean is that Apple
| Store employees have neither procedure nor access to override
| Apple's account system. You have to call support for
| assistance beyond what the website can do. I am sure Apple
| Store employees have been helpful and I'm sure policies have
| changed over time.
|
| As an Apple user I find this as frustrating as it is wise.
| Mostly for future-me who may one day not be as savvy and
| manage to screw myself.
|
| I don't fully trust iCloud Keychain and Apple to never lose
| my data in a "I don't concern myself with backups" manner. So
| I opt for using Passkeys where I can also add my FIDO2
| tokens.
| dijit wrote:
| Eh. Pedantically; the Apple Store will at least try to help
| you, even if they're not empowered to fix it they will
| guide you through the process until there is a resolution.
|
| It's not as "you're on your own" as some products I've
| owned.
| r00fus wrote:
| This is key. That the Apple Store can't directly help you
| doesn't mean they won't direct you to the proper person
| (and possibly stay with you if possible & desired)
| quadrifoliate wrote:
| I suspected this, which is why I accounted for it - the
| point is that if Apple started getting enough bad press,
| they _would_ have to put Apple ID verification in their
| stores, because their customers are the people who pay for
| Apple products.
|
| Google's customers are mostly the people that get to show
| you ads. So they don't seem to care about even the _paying_
| users for their products. And it 's sad that Apple seems to
| be going the way of trying to be an ad platform as well.
| jeroenhd wrote:
| Can we have this but self-hostable and open source, please?
| Something like Bitwarden that you can stuff onto your own device?
| I know there are hosted services for handling auth on the server
| backend, but what about the other way around?
|
| I use Krypton but that's not maintained (and already broken on
| some websites like Github). I trust the secure storage module of
| my phone and I trust my computer's TPM, unlike many other Linux
| users; surely it should be possible to integrate with the OS
| somehow to make it secure, right? The last example I saw used USB
| over IP to inject a virtual FIDO device, which works great, but
| the implementation is clearly not ready for prime time.
| colordrops wrote:
| Ugh, I hope they don't make it difficult to use third party
| password managers. I'm pretty happy with vault warden.
| selykg wrote:
| Pretty sure there's been talk on the Bitwarden community forums
| about them adopting support for using it as a provider. I
| assume once that's available you might start to see it move
| into Vaultwarden. But, that's sort of the risk you run with
| using a 3rd party to a 3rd party...
| colordrops wrote:
| At least with Vaultwarden, it's open source and running
| locally with data stored on a server in my house, so if they
| misbehave, I could easily fork or switch projects. If Android
| doesn't allow or otherwise hobbles 3rd party password
| managers, there isn't much recourse.
| selykg wrote:
| That's fair, but Bitwarden itself is also open source...
| though, my understanding is significantly more difficult to
| get up and running than Vaultwarden.
| xg15 wrote:
| Dumb question: what keeps me from spoofing the fingerprint[1] and
| obtaining all the passcodes at once?
|
| [1] https://phys.org/news/2005-12-biometric-expert-easy-spoof-
| fi...
| chocolatkey wrote:
| Note you can't just get the keys even if you have a
| fingerprint. You would need to maintain continuous access to
| the device while it is still signed in as the user. It would be
| pretty easy to the "find my device", if the user didn't already
| notice you were handling it
| wnevets wrote:
| Passkeys sound like another way for companies like Google and
| Apple to lock you into their walled garden. Having each walled
| garden randomly generating a key for every single domain instead
| of using the actual domain name as part of the key is a great way
| to lock regular people into their respective ecosystems.
| redandblack wrote:
| yeah. will be switching to this for all google apps, with
| firefox for general use
| skybrian wrote:
| Seems like you wouldn't want to share passkeys for the same
| reasons you don't normally want to share passwords?
|
| Instead, each website that accepts passkeys should allow you to
| register multiple devices and probably print out backup codes
| as well (for the especially important accounts).
|
| If there's no reason to migrate anything then lock-in is
| irrelevant. Just add more login methods so that when you lose
| some, you have others.
| throwaway41597 wrote:
| The lock-in is very real and relevant.
|
| Websites already have a hard time to get users to sign up, so
| requiring them to enroll backup authenticators (which they
| won't have) is not going to work. Printing or writing down
| backup codes is even worse from a UX point of view.
|
| IIRC the spec has a flag to hint that the passkey is backed
| up (in iCloud or your Google account) so the relying party
| (website) knows whether backups are mandatory but that means
| the secret doesn't stay on your device and goes to the
| mothership. Then I don't see why the spec wouldn't
| standardize the transfer of secrets from one company to the
| other.
| jjnoakes wrote:
| I have over 500 online accounts. Imagine if all of them used
| a login method where I had to have backup devices registered,
| instead of just me backing up the credentials (like I do
| today with a password manager).
|
| With backup devices, whenever I upgrade or replace a device,
| I need to go to each of the 500+ online accounts and register
| the new device. This is much more work than a quick login to
| each site via my password manager (which can happen on-
| demand, only as I need to use the services).
| dickhardt wrote:
| I founded Hello to solve this problem. A neutral service
| where you get to choose how to login, and how you can
| recover your Hello Wallet. Done.
|
| See Show HN post I wrote this morning
| https://news.ycombinator.com/item?id=33178285
| skybrian wrote:
| Yeah, this is why I connect unimportant accounts to Google
| or GitHub, and use two step auth only for the important
| ones.
| api wrote:
| The entire third party auth push has turned into what may be
| one of the largest incumbent power grabs I have ever seen.
| Stuff like Google Amp or even App Store walled gardens pale in
| comparison.
|
| What drives me nuts is how little discussion of this I've seen.
| People don't even seem aware of the implications of it. It's
| being pushed hard as a boon to security, which it is in some
| cases, but at a cost that nobody is even considering or talking
| about.
|
| The implications are pretty profound: large companies having
| the power to lock you out of _everything_ on a whim (even your
| own systems and unaffiliated third party services), levy taxes
| on the use of everything (e.g. Google starts charging you or
| sites to log in with Google), surveil literally everything
| (including logging into everything you have as you and sucking
| down data), and if a big identity provider gets seriously
| hacked it 'll be an epic security apocalypse. Imagine someone
| stealing the master keys for a provider and pushing ransomware
| to _millions_ of companies at once.
|
| ... and don 't forget the obvious: "Oops I got locked out of
| Google and now I'm locked out of 50 SaaS services, my company's
| bank, my VPN, and my remote servers."
|
| It just totally blows me away that these systems have no
| privacy protection at all, no portability provision for me to
| select or change my provider built into the protocol, no built-
| in support for third factor auth that I can control (e.g.
| FIDO2), no built in provision for recovery codes, and so on.
| These kinds of things didn't even seem like they were
| considered in the design of things like OpenID/OIDC. It's just
| a big "oh hey lets give god level access with no recourse to
| third parties and implement it so there's total lock-in... what
| could go wrong?"
|
| Edit: yes some well-implemented systems offer their own built-
| in support for _some_ of those things (recovery codes, changing
| your auth provider, reverting to password, etc.) but in my
| experience it 's a minority and there is obviously nothing in
| the standard to encourage it or provide any guidance on how to
| do those things securely.
| r00fus wrote:
| Compare this with status quo for users like my parents. They
| constantly forget their passwords and quail at screwing up
| the 2nd factor all the time.
|
| If they could just use their fingerprint/faceID to login
| (after initial registration on the device) they would be
| super happy.
|
| Rest of us should be happy there will be less exploits where
| people give up the keys to their kingdom by clicking on a
| random email.
| jve wrote:
| Exactly what Google thinks:
| https://youtu.be/N7N4EC20-cM?t=15m36s
|
| If you scroll back, they mention you have to protect
| everyone to be effective, i.e. high value target friends
| and family.
| dickhardt wrote:
| I founded Hello to address your concerns. Check out the Show
| HN post I wrote this morning.
| https://news.ycombinator.com/item?id=33177705#33182379
| mooreds wrote:
| My understanding of passkeys is that they are using WebAuthn
| under the hood (hence the nod to the w3c/FIDO at the end, and
| the fact that the passkey in the screenshot was associated with
| tribank.us).
|
| They are solving a very real problem. WebAuthn uses private
| keys, but those private keys are tied to the device where they
| were created. This is a blessing and a curse.
|
| It's a blessing because it eliminates a whole trove of phishing
| attacks. After all, if no one can get the private key, they
| can't steal or share it. Well, of course they could steal the
| actual device, but that's orders of magnitude harder than
| stealing online credentials (points to
| https://haveibeenpwned.com/ ). That's a good thing.
|
| It's a curse because the same person logging in from their
| ipad, android phone, and desktop PC needs to set up WebAuthn
| three times. For each domain/website (broadly speaking). If
| they only set it up once and lose the device, well, they are
| either locked out or need to have another means of account
| recovery (username/password, calling a customer service rep).
|
| This curse is what passkeys managed by Apple/Google are
| attempting to solve.
|
| I believe the WebAuthn 3 draft is going to try to address some
| of this: https://www.w3.org/TR/webauthn-3/ but that's based on
| what a co-worker said. A quick scan didn't turn up anything.
|
| If you want to know more about WebAuthn, I wrote a lot more
| here (my company is going to release an implementation Real
| Soon Now): https://fusionauth.io/learn/expert-
| advice/authentication/web...
| wnevets wrote:
| > They are solving a very real problem. WebAuthn uses private
| keys, but those private keys are tied to the device where
| they were created.
|
| To clarify I am not talking about the issue of syncing the
| device's private key. I am talking about the artificial
| problem these walled gardens are creating by having every
| single domain getting its own randomly generated private key.
| The only _practical_ way to keep all of these randomly
| generated keys synced across multiple devices is to use the
| "cloud".
|
| If instead the per site key was generated using a private key
| and the domain name, users would only need to transport that
| one private key to another device and would get syncing for
| free without the requirement of the "cloud".
| yakak wrote:
| Every site is supposed to be keeping its randomly generated
| data to give back to you as an input to proving you have
| the device, but no one wants to give the relying parties
| open source "enterprise authentication" for free like in
| the days when Apache was king..
|
| I don't really see a safe way to do what fido was trying to
| do while letting keys flow about and using their cloud for
| the original setup with the security we were originally
| expecting wouldn't have the conveniences they are talking
| about.. So it seems like more phishing, now for getting an
| activated device/chrome session.
| josteink wrote:
| > I am talking about the artificial problem these walled
| gardens are creating by having every single domain getting
| its own randomly generated private key.
|
| That's part of the design though. That's what completely
| eliminates the ability to do phishing-attacks.
|
| If there were a common root to leak, that would just
| provide a new target for phishing attacks, and effectively
| risk reducing a persons entire online security down to 1
| shared root-key.
|
| While obviously better than having just 1 common shared
| password, why reintroduce this risk when you don't have to?
| wnevets wrote:
| > That's part of the design though. That's what
| completely eliminates the ability to do phishing-attacks.
|
| If the actual domain name is used to generate the key
| that would also completely eliminates the ability to do
| phishing-attacks. Paypal.com and PaypaI.com would
| generate two completely different keys.
| josteink wrote:
| It would mean that somewhere there is a common root,
| which if extracted, can derive all keys for all sites.
|
| Why introduce such a risk when there's no reason to do
| that?
| wnevets wrote:
| If I can get access to your device to exfiltrate the
| private key that generates the domain specific keys, why
| wouldn't I also have access to the the randomly generated
| site keys? Your device needs access to the keys to use
| them.
|
| In both cases your device has a private key that it needs
| to secure. In my scenario we remove the third party cloud
| service.
| xg15 wrote:
| Because then as a user you'd still have the ability to
| backup that key yourself and aren't at the mercy of
| $cloud_service_of_your_choice.
| [deleted]
| josteink wrote:
| > it's a curse because the same person logging in from their
| ipad, android phone, and desktop PC needs to set up WebAuthn
| three times.
|
| Or just get some Yubikeys.
| webmobdev wrote:
| This is also going to be a body blow for our privacy - if
| BigTech have access to your keys, so will the government and
| both can abuse it. The idea is to _force_ you to _" save
| password on device"_ (whether you want to or not) so that when
| a government authority gets your device they can also easily
| access all your internet accounts. US courts have already
| affirmed that it is legal for the police to force you to unlock
| your device if it is biometric protected (fingerprint or face
| scan etc.). Moreover, by forcing you to use your personal
| device for identity verification, BigTech is ensuring that
| identifying you and datamining your personal data becomes more
| easy for them. Don't be surprised if this is also extended in
| the future as a "super cookie" service to allow easy tracking.
| yupper32 wrote:
| Why would this be different than any other password manager
| in that aspect?
| goalieca wrote:
| There will be services from 1password, yubikey, etc. This is
| actually great news!
| [deleted]
| fotta wrote:
| Google's auth is getting increasingly frustrating. Recently when
| I logged in with TOTP 2FA, I had to also open up YouTube on
| another device and click approve. What's the point of 2FA if
| they're just going to ignore it?
| htrp wrote:
| Welcome to user hostile revenue maximization algorithms
| politelemon wrote:
| > A passkey on a phone can also be used to sign in on a nearby
| device. For example, an Android user can now sign in to a
| passkey-enabled website using Safari on a Mac. Similarly, passkey
| support in Chrome means that a Chrome user, for example on
| Windows, can do the same using a passkey stored on their iOS
| device.
|
| > Since passkeys are built on industry standards, this works
| across different platforms and browsers - including Windows,
| macOS and iOS, and ChromeOS, with a uniform user experience.
|
| I see no mention of Linux in these examples, which tells me that
| users having access to their keys is not a primary concern for
| these implementations?
| madjam002 wrote:
| See also
| https://security.googleblog.com/2022/10/SecurityofPasskeysin...
| which provides a more technical overview
| dickhardt wrote:
| Q: how many of you will add support to Passkeys to your
| application? Is it worth the effort of adding yet-another-way-to-
| login for your users? It will be a long time before you could use
| it as the ONLY way to login. You will need to figure out how to
| enable your existing users to convert to Passkeys. Apple has a
| glide path for converting username password -> but not for other
| mechanisms.
|
| I believe we in letting the user choose whatever way is best for
| them to login -- and to take that burden off of the developer. If
| you want to learn more, check out the Show HN post on Hello I
| wrote this morning.
| https://news.ycombinator.com/item?id=33177705#33182379
| LibertyBeta wrote:
| Interesting. I'm still struggling to see how this is better than
| just using a yubi/solo-key
| sowbug wrote:
| "To address the common case of device loss or upgrade, a key
| feature enabled by passkeys is that the same private key can
| exist on multiple devices. This happens through platform-
| provided synchronization and backup."
|
| Thus, unlike a FIDO2 key, you don't have to visit every online
| service to tell it about the new redundant keys you add.
|
| The rest of the security article linked by madjam002 goes into
| detail how Google implements their version of that backup. It's
| a bit like Keybase in the sense that your other devices act as
| keys to unlock the backup for new devices.
| aseipp wrote:
| At the very minimum, one undeniable technical advantage
| Passkeys have -- that they share with their foundation,
| WebAuthn -- is that Passkeys are unphishable.
| eli wrote:
| More people own an Android phone than a yubikey?
| jrm4 wrote:
| More convenient, but less safe for everyone in the long run.
| runako wrote:
| Passkey will be supported, with no new user behavior, by ~a
| billion devices currently in use. It is better because a
| billion+ devices already have support for this.
| selykg wrote:
| I would use this in addition to those. Instead of having to buy
| two Yubikeys I can buy one and use a software solution as well.
|
| Since I already use a phone capable of doing the same thing,
| let my phone be my main authenticator, and then I can use a
| Yubikey as a backup.
|
| It's not like one is necessarily better than the other, except
| that you already carry a phone and they're capable of being a
| hardware device that works with Webauthn. No need to carry a
| second device or, pay for one, for that matter. Since at least
| with Apple's solution it'll sync over iCloud Keychain.
|
| If you're happy with Yubikey's, nothing changes. But for the
| average person, this makes Webauthn an option without having to
| buy any hardware or carry something you are more likely to lose
| because you don't understand the intricate details of how the
| thing works. I wouldn't expect my parents to understand how a
| Yubikey works well enough to know it should be used as a pair,
| for backup purposes, but that is a barrier to entry for them
| that they don't need to worry about now.
| LibertyBeta wrote:
| That makes sense. I do worry we are starting to build key
| chains that are leveraged obliquely to the user.
|
| Once passkey support comes to bitwarden I'll be a little more
| comfortable I think.
| mpalmer wrote:
| This is public-key-crypto-based authentication for the average
| user who will almost certainly never buy a security key but who
| probably owns a device that offers secure identity verification
| (laptop, phone).
|
| Yubikeys are great but they're super niche. Among Android users
| alone there might be a billion people who will never buy one.
| jasonjayr wrote:
| And what happens if your Google account that these keys are tied
| to is locked/revoked for a nebulous ToS violation?
| sowbug wrote:
| From TFA (the security blog): "The main ingredient of a passkey
| is a cryptographic private key. In most cases, this private key
| lives only on the user's own devices, such as laptops or mobile
| phones."
| waynesonfire wrote:
| so what? maybe it is also pinned to your google account so
| regardless that it's a private key that only lives on your
| device, doesn't at all mean you can somehow transfer it. it
| could simply be one of many components that make up the
| effective key.
| xg15 wrote:
| "on your device" doesn't mean that you can actually access
| the key though. It might be stored in the secure enclave/TPM
| or otherwise unavailable if the phone has a locked
| bootloader.
| toomuchtodo wrote:
| Final step is key escrow authority that will store your
| private key and produce it to you if you can proof your
| identity with government ID. It is not enough to store in
| cloud storage (which Google, Apple, or someone else could
| deny you access to), or your own device you could lose or
| destroy (which is why backup hardware tokens are always
| recommended for U2F MFA); you need the ability (but not a
| requirement) to bind cryptographic identity to IRL identity.
|
| Of course, one doesn't _need_ to utilize this, but you're SOL
| without a recovery mechanism of last resort (unless
| individual sites and services have their own recovery
| processes to re-provision a user who no longer has access to
| their cryptographic credentials).
| tialaramex wrote:
| For the vast majority of services, there's no value or even
| negative value in binding my "identity" to some sort of
| government ID.
|
| You accept Google and Apple might deny you access but then
| you just blithely assume the US Federal Government (for
| example) would never do so, which shouldn't pass the laugh
| test.
|
| I can imagine it being valuable if my government wants to
| help get me back in to, say, my bank accounts if I somehow
| lost all my credentials (e.g. my home burned down suddenly
| but I somehow escaped with nothing). But I don't feel like
| my GitHub, Gmail, Patreon, etc. make sense in this context.
| If my friends can lose a phone every year or two and make a
| new god-damn account, I think "My home burned down and I
| have nothing" is a good enough reason.
|
| Gitlab's attitude of (for unpaid accounts): Too bad, just
| make another one - seems appropriate for almost everything.
| If tialaramex never wrote another HN comment, and instead
| tlrmx or tialaramex2 or whatever began posting, who would
| even care ?
| toomuchtodo wrote:
| HN participants, for whatever reason, approach these
| challenges as "but this isn't a problem I have." You're
| the builder (broad strokes and wild assumption), but
| there are far more citizens (hundreds of millions at
| least) who are simply consumers of these systems. They
| are your grandparents, your parents, your siblings, your
| children. Passkeys are rolling out internet wide to all
| sorts of critical services people rely on, and they'll
| need a solution if they lose their cryptographic identity
| assertion, because you can't always just create a new
| account when you lose access (either because data,
| finance, or authority is tied to that account). Loss of
| gitlab access is inconsequential compared to losing
| access to your email, your bank account, etc.
| sebk wrote:
| FIDO credentials have some baked in assumptions about the
| cryptographic properties they were generated with, that an
| RP can use to reason about credential strength, and are
| designed so that unwrapped private keys are not handled
| outside of an authenticator device. These assumptions make
| it undesirable for sync fabric vendors to interoperate.
|
| You are correct that a Passkey ecosystem has an inherent
| risk of being locked out of cloud storage / sync, and that
| a third party escrow system is a mitigation against that.
| But it's not sufficient. You'd end up with keys that could,
| at best, only be imported into authenticators of the same
| ecosystem you were denied access from which, as Sync
| Fabrics are not interoperable. This is presumably not the
| outcome you're looking for.
|
| I believe some sort of mechanism to assert credential
| strength at presentation time rather than generation time,
| and/or some sort of mechanism for TPMs/Secure
| Elements/Secure Enclaves to establish trust and import
| trusted credentials from a different authenticator vendor
| would be needed. This would allow vendors that don't
| control the hardware (i.e. are not Apple/Google/Microsoft)
| to build something like a "1Passkey" without having to
| implement their authenticators in software (i.e. a Virtual
| Authenticator), and you could keep your wrapped passkey
| store in escrow with any third party of your choosing.
| EvanAnderson wrote:
| In the United States the US Postal Service would be a great
| fit for a job like this. They already have good
| infrastructure for identity verification and physical
| distribution.
|
| I wouldn't want escrow of private keys, however. I'd rather
| the USPS just act as a certification authority that
| provides strong guarantees of identity verification.
| collegeburner wrote:
| i don't want this because then more websites will start
| expecting strong identity verification. the last thing we
| need are more attacks on anonymity. at least with a
| private key i can say i'm joe biden or crazy horse or
| whoever. i may not be eligible for "government escrow"
| but who cares.
| EvanAnderson wrote:
| It's a double-edged sword for sure.
|
| My bank is already regulated and required to have strong
| identity verification for some operations. They won't let
| use any sensible multi-factor authentication, however.
| Requiring they use such a government mandated
| authentication infrastructure would be a major "win" for
| my piece-of-mind.
| toomuchtodo wrote:
| Yes, definitely. USPS + Login.gov could act as trust
| anchors, with cryptographic keys reprovisioned upon
| proofing, versus storing them. I am open to whatever is
| the optimal balance between security and practicality.
|
| https://www.uspsoig.gov/document/role-postal-service-
| identit...
|
| > The Postal Service Reform Act of 2022 has recently
| expanded the Postal Service's ability to provide identity
| verification to all levels of government. A window of
| opportunity is currently open for USPS to contribute to
| closing gaps in government identity verification
| processes.
| numbsafari wrote:
| Except that here in the US a non-trivial number of
| politicians of a particular persuasion[1] actually
| believe that government issued ID, of any kind, is the
| "mark of the beast". There's a reason that Real ID had a
| lot of push back. Having USPS, already a political bogey-
| man for that same crowd, become a holder of "identity" is
| probably going to face a lot of pushback.
|
| [1] just one, recent example...
| https://www.al.com/news/2022/10/alabama-gop-chairman-
| made-th...
| hcurtiss wrote:
| I can assure you that a lot more constituencies than just
| the Christian coalittion are concerned about universal
| government-issued IDs as passports for online
| participation.
| 988747 wrote:
| I think it's mostly because easily obtainable government
| ID will make it easy for Black and Latino people to
| register for vote, which means Republicans will never win
| any election ever again :)
| billiam wrote:
| Pass it anyway. Happy to see them refuse to participate.
| collegeburner wrote:
| because simple, easy-to-use ID lowers the barrier for
| demanding ID in more places and attacking anonymity. the
| easier we make it to demand id, the more people will
| demand it. wanna use a fake name/not divulge your
| identity? doing something politically sensitive where you
| may need some protection? just like your privacy? tough
| shit show your id or GTFO.
| ivanhoe wrote:
| Shouldn't we instead solve the problem that you might
| "need some protection" because you're doing something
| political - instead of relying on security-through-
| obscurity which honestly doesn't even really work
| anymore, IDs or no IDs. There's so many other ways for
| governments to track people of interest these days.
| collegeburner wrote:
| i disagree with the assumption that it's a solvable
| problem. people remain fallible and the correct solution
| is to mitigate our downside by minimizing state power.
| not disagreeing with the idea that we also need to work
| on lots of other ways to reduce its power and ability to
| track people btw.
| ur-whale wrote:
| Except for the fact that a mobile phone does not, as far as
| I'm concerned, fall in the "user's own device" category, as
| much as Google would like you to believe it does.
| megous wrote:
| "Passkeys on users' phones and computers are backed up and
| synced through the cloud to prevent lockouts in the case of
| device loss."
|
| "Only on the user's device", right.
| olliej wrote:
| They way keys are managed means that the passkey material
| is never available to Google, Apple, etc
| mixedCase wrote:
| Are the keys encrypted with a key derived from a master
| password?
|
| Does the decryption only occur on the user's device?
|
| Is this master password not reused for the account or has
| account authentication been changed to use a
| cryptographic proof produced on-device?
|
| If the key is ever decrypted on vendor's servers,
| everything else is theater.
|
| And this is all of course also excluding auto-updating
| vendor-supplied authentication code from the threat model
| because the industry is not ready for that conversation
| yet.
| joshuamorton wrote:
| tl;dr: Yes, and further they're only decrypted using the
| secure chip on the device, so the vendor supplied
| authentication firmware can't be updated without user
| interaction/approval.
|
| From a post linked in the article:
|
| > Passkeys in the Google Password Manager are always end-
| to-end encrypted: When a passkey is backed up, its
| private key is uploaded only in its encrypted form using
| an encryption key that is only accessible on the user's
| own devices. This protects passkeys against Google
| itself, or e.g. a malicious attacker inside Google.
| Without access to the private key, such an attacker
| cannot use the passkey to sign in to its corresponding
| online account.
|
| > Additionally, passkey private keys are encrypted at
| rest on the user's devices, with a hardware-protected
| encryption key.
|
| > Creating or using passkeys stored in the Google
| Password Manager requires a screen lock to be set up.
| This prevents others from using a passkey even if they
| have access to the user's device, but is also necessary
| to facilitate the end-to-end encryption and safe recovery
| in the case of device loss.
| tgsovlerkhgsel wrote:
| The question I always ask to figure out how things work:
| What happens if I lose my phone?
|
| Vendors trying to peddle a solution will always try to
| answer this question in a way that doesn't say "well in
| that case you're screwed" and any answer except "you're
| screwed" means there is _some_ kind of potentially-
| vulnerable recovery process, and the description of how
| the process works usually gives you an idea of how secure
| it is (or at least a starting point to ask more
| questions).
| olliej wrote:
| If you lose your phone (and all other devices you might
| have), apple does have a secure (as in apple cannot
| access it) last ditch recovery path (see my other wall of
| text/word soup answer).
|
| But in the absence of that the data is gone - it's one of
| the big concerns that come up in response to "E2E
| everything": people are not used to the idea that
| forgetting your password (or losing devices in a 2fa
| world) means the data is actually irrecoverable and it's
| not just a matter of reseting the account password (e.g.
| you can't go into a store with your ID to "prove it's
| you" because that isn't the problem)
| olliej wrote:
| > Are the keys encrypted with a key derived from a master
| password?
|
| No, because PBKDFs are not a good mechanism for creating
| encryption keys. Instead you have an actual random key,
| and your devices gate access to that key with your device
| password.
|
| > Does the decryption only occur on the user's device?
|
| Yes, because only the user's devices have access to the
| key material needed to decrypt. Apple _cannot_ decrypt
| them.
|
| > Is this master password not reused for the account or
| has account authentication been changed to use a
| cryptographic proof produced on-device?
|
| Not sure what you're asking here?
|
| > If the key is ever decrypted on vendor's servers,
| everything else is theater.
|
| As above the vendor/apple _cannot_ decrypt anything[1]
| because they do not have key material.
|
| > And this is all of course also excluding auto-updating
| vendor-supplied authentication code from the threat model
| because the industry is not ready for that conversation
| yet.
|
| Don't really agree. The malicious vendor update is
| something that is discussed reasonably actively, it's
| just that there isn't a solution to the problem. Even the
| extreme "publish all source code" idea doesn't work as
| auditing these codebases for something malicious is
| simply not feasible, and even if it were ensuring that
| the course code you get _exactly_ matches the code in the
| update isn 't feasible (because if you assume a malicious
| vendor you have to assume that they're willing to make
| the OS lie).
|
| Anyway, here's a basic description of how to make a
| secure system for synchronizing anything, including key
| material (secure means "no one other than the end user
| can ever access the key material, in any circumstance
| without having broken the core cryptographic algorithms
| that are used to secure everything").
|
| Apple has some documentation on this scattered around,
| but essentially it works like this:
|
| * There is a primary key - presumably AES but I can't
| recall off the top of my head. This key is used to
| encrypt a bunch of additional keys for various services
| (this is fairly standard, the basic idea is that a
| compromise of one service doesn't compromise others - to
| me this is "technically good", but I would assume that
| the most likely path to compromise is getting an
| individual device's keys in which case you get everything
| anyway?)
|
| * The first device you use to create an iCloud account or
| to enable syncing generates these keys
|
| * That device also generates a bunch of asymmetric keys
| and pushes public keys to anywhere they need to go (i.e.
| iMessage keys)
|
| * When you add a new device to your account it messages
| your other devices asking to get access to your synced
| key material, when you approve the addition of that new
| device on one of your existing ones, that existing device
| encrypts the master key with the public key provided by
| your new device and sends it back. At that point the new
| device can decrypt that response and use that key to then
| decrypt other key material for your account.
|
| All this is why in the Apple ecosystem if you lose all
| your devices, you historically lost pretty much
| everything in your account.
|
| A few years ago Apple introduced "iCloud Key Vault" or
| some such marketing name for what are essentially very
| large sets of HSMs. When you set up a new device that
| device pushes its key material to the HSMs, in what is
| functionally plaintext from the point of view of the
| HSMs, alongside some combination of your account password
| and device passcode. You might now say "that means apple
| has my key material", but Apple has designed these so
| that it cannot. Ivan Krstic did a talk about this at
| BlackHat a few years back, but essentially it works as
| following:
|
| * Apple buys a giant HSM
|
| * Apple installs software on this HSM that is essentially
| a password+passcode protected account->key material
| database
|
| * Installing software on an HSM requires what are called
| "admin cards", they're essentially just sharded hardware
| tokens. Once Apple has installed the software and
| configured the HSM, the admin cards are put through what
| Krstic called a "secure one way physical hashing
| function" (aka a blender)
|
| * Once this has happened the HSM rolls its internal
| encryption keys. At this point it is no longer possible
| for Apple (or anyone else) to update the software, or in
| any way decrypt any data on the HSM.
|
| * The recovery path through requires you to provide your
| account, account password, and passcode, and the HSM will
| only provide the key material if all of those match. Once
| your new device gets that material it can start to
| recover all the other material needed. As with your phone
| the HSM itself has increasing delays between attempts.
| Unlike your phone once a certain attempt count is reached
| the key material is destroyed and the only "recovery
| path" is an account reset so at least you get to keep
| your existing purchases, email address, etc.
|
| You might think it would be better to protect the data
| with some password derived key, but that is strictly
| worse - especially as the majority of passwords and
| passcodes are not great, nor large. In general if you can
| have a secure piece of hardware gate access to a strong
| key is better than having the data encrypted to a weak
| key. The reason being that if the material is protected
| by that key rather than enforced policy then an attacker
| can copy the key material and then brute force it
| offline, whereas a policy based guard can just directly
| enforce time and attempt restrictions.
|
| [1] Excepting things that aren't end-to-end encrypted,
| most providers still have a few services that aren't E2E,
| though it mostly seems to be historical reasons.
| [deleted]
| throwaway41597 wrote:
| > No, because PBKDFs are not a good mechanism for
| creating encryption keys
|
| I'm curious about what you mean by this. Isn't it in part
| what PBKDFs are designed for?
| olliej wrote:
| sowbug has a more detailed answer, but the TLDR is the
| PBKDFs were consider ok a long time ago before the
| security implications were really understood. Essentially
| they're low entropy in practice (e.g. a person _could_
| make a 10+ word password, but they're not going to for a
| password they have to enter frequently).
|
| You're much better off using the password to a truly
| random key, though that of course immediately raises the
| question of how you store the true key :D Modern systems
| use some kind of HSM to protect the true keys, and if
| they're super integrated like the SEP (or possibly the
| SE, I can never recall which is which) on apple hardware
| they can simply never expose the actual keys and only
| provide handles and have the HSM encrypt and decrypt data
| directly before it's seen by the AP.
| sowbug wrote:
| _> > No, because PBKDFs are not a good mechanism for
| creating encryption keys_
|
| _> I 'm curious about what you mean by this. Isn't it in
| part what PBKDFs are designed for?_
|
| Password-based key derivation functions start with the
| assumption that some entropy is provided by the user.
| Which means that the entropy is typically of awful
| quality. A PBKDF does the best it can with that low
| entropy, which is to make it into a time- and maybe
| space-expensive brute-forcing problem. But a PBKDF is
| starting with one hand tied behind its back if the user-
| supplied entropy is "password" or "hunter2." If we aren't
| burdened by that assumption, then we can generate high-
| quality entropy -- like 128 or 256 bits of CSRNG-
| generated noise -- and merely associate it with the user,
| rather than basing it on the user's human-scale memory.
|
| PBKDFs also generally assume that users are transmitting
| their plaintext passphrases to the server, e.g., when you
| HTTP POST your credentials to server.com. Of course,
| browsers and apps use transport security so that MITMs
| can't grab the passphrase over the wire, but the server
| actually does receive the phrase "hunter2" at some point
| if that's your passphrase. So again, it's a rotten
| assumption -- basically the foundation of most password-
| database compromises on the internet -- and PBKDF does
| the best it can.
|
| If you remove that assumption and design a true
| asymmetric-encryption-based authentication system, then
| you don't need the obfuscation rounds of a PBKDF because
| the asymmetric-encryption algorithm is already resistant
| to brute-forcing. The script kiddie who steals
| /etc/passwd from a server would effectively obtain a list
| of public keys rather than salted hashes, and if they can
| generate private keys from public keys, then they are
| already very wealthy because they broke TLS and most
| Bitcoin wallets.
|
| Think of passkeys as a very user-friendly client-side
| certificate infrastructure. You wouldn't let your
| sysadmin base your enterprise website's TLS certificates
| on a private key derived from their dog's birthday. You
| wouldn't let users do that for their certs, either.
| googlryas wrote:
| I suppose you would just do the "I forgot my passkey" flow.
| insane_dreamer wrote:
| can you download/print backup recovery codes?
| ezfe wrote:
| At least on iOS, passkeys are stored locally in Keychain, even
| if they're also synced over iCloud (when enabled).
| zie wrote:
| In my experience on iOS, you can't make Passkeys work without
| also turning on syncing, that's sort of the entire point of
| Passkeys, otherwise they would just be WebAuthN tokens.
| jrm4 wrote:
| Nah.
|
| For all the talk of "one app to rule them all" (which is an awful
| idea) this is a step closer to that.
|
| For all it's faults, crypto has one thing right -- not your keys,
| not your stuff. I get that doing keys/passwords is hard, but the
| best thing in the long run is for them to stay in the hands of
| the user.
|
| And if not, the holder of the keys needs to be someone you can
| easily hold accountable, i.e. either fire, or arrest, or sue if
| they get it wrong.
| mindslight wrote:
| > _For all it 's faults, crypto has one thing right -- not your
| keys, not your stuff_
|
| Erm, this isn't really an aspect of cryptocurrency, per se.
| It's more of a general rule that informed the initial thinking
| around cryptocurrency. In fact, most users of cryptocurrency
| seem quite content to give up cryptographic custodianship.
|
| If you went back a similar time to the nascent web/cloud/etc,
| you'd find plenty of similar sentiment about remote software
| and storage. It's just that individual autonomy loses out over
| time due to convenience created by the massive investment in
| the surveillance economy.
| jrm4 wrote:
| That's a fair point, in that I should have said something
| like "crypto-fundamentalists." But the idea is the one I
| wanted to get across, and I have mostly those same feelings
| about remote software and storage (e.g. I tell students,
| priority one in your life -- if there's something digital you
| care about, e.g. photos, get at least one copy of them on
| something you can hold in your hand)
| jackson1442 wrote:
| it is your key, it lives on your device (and is synced across
| devices using your cloud account if you so choose)
| jrm4 wrote:
| It's a nanny-ish third-party in the middle. That increases
| convenience, but also _greatly_ increases your threat
| surface.
| jackson1442 wrote:
| Is it nanny-ish just because it makes it simpler for end
| users? Fairly certain most users are not interested in
| managing their own key sharing infrastructure.
|
| It's built on the same technology as FIDO keys, so if you
| want to take control of it yourself, just use a hardware
| key.
| jrm4 wrote:
| Exactly.
|
| Now, why are they doing it for free? Why take on a huge
| responsibility for no money, what do they get out of it?
| joshuamorton wrote:
| Be precise: what threat is added here that is added by a
| third party holding encrypted keys?
|
| Like this isn't particularly different from me backing up
| my (encrypted) disk which contains my (further encrypted)
| keys to the cloud somewhere.
| politelemon wrote:
| In the second instance, you are controlling the where and
| how of your keys being backed up. If you are smart you
| will have backed up your keys to multiple locations, for
| disaster recovery. One of the fundamentals of privacy is
| having control of your data, which the first option does
| not provide.
| joshuamorton wrote:
| Why not?
|
| What is concerning about giving encrypted keys to
| someone? If I give my encrypted key to you, right now, I
| retain control of my data. One of the fundamentals of
| encryption is that you can freely share the ciphertext
| without giving up control of your data.
| jrm4 wrote:
| I don't know, and you don't either, because I'm willing
| to bet that "Google" is smarter than both of us.
|
| That's kind of the point. We have to trust that Google
| won't mess things up and we have essentially no recourse
| if they do.
| joshuamorton wrote:
| I'm unclear on what you think they could do. Is your idea
| here that Google is so smart that they can break end to
| end encryption? If so, we've got bigger problems.
|
| It isn't fair to presume that everyone shares your lack
| of knowlege on a subject, and it's simply incorrect to
| presume that because you don't understand something that
| it _cannot_ be safe or reliable.
| jrm4 wrote:
| What they say today about end-to-end encryption seems
| like it should work fine from a technical point of view.
| It is entirely possible the Google is very good about
| this, and when implemented, it might work perfectly as
| stated today.
|
| But I'm not talking about incorrect or correct and I
| don't care about fairness in presuming whoever's
| intelligence either, because the thing I'm talking about
| is more important, which is _risk._
|
| Large companies taking on big tasks that you don't pay
| them for is undeniably _risky_ for many reasons. One,
| they screw it up today. Two, they don 't screw it up
| today but they change it tomorrow. We know this because
| many of these companies have done things like this
| before.
| joshuamorton wrote:
| But again, what is the unique risk here? Google shutters
| and your phone bricks simultaneously, and you're left
| unable to log in?
|
| Like this is lower risk than a local password manager or
| a yubikey or... Because it's both local and cloud backup.
| Be precise, what is the risk?
| mtlmtlmtlmtl wrote:
| A nanny-ish third party, as opposed to Coinbase, Binance,
| et al?
| jrm4 wrote:
| No, those are the same thing. The "not your keys" thing
| in crypto is exactly the reason they tell you NOT to
| store your crypto with e.g. Coinbase/Binance. Just use
| them as on/off ramps, but have your own wallet.
| webmobdev wrote:
| And BigTech's cloud (who will have no problem sharing it with
| the authorities). And when all your keys are on the device,
| it also becomes a lot easier for the government to access all
| your internet accounts by getting access to the device.
| jackson1442 wrote:
| They're end-to-end encrypted. Did you read the article?
|
| This is the same threat model as password managers, which
| are generally approved of on HN.
| jrm4 wrote:
| Yeah, I think HN is mostly wrong about those as well. :)
| tjoff wrote:
| You can backup your password manager.
|
| You don't have to depend on the cloud for your password
| manager.
| ok_dad wrote:
| Try telling the authorities you "forgot" your password when they
| know you use passkeys.
| greatgib wrote:
| Another product that they will use their dominant position to
| force down our throat!
| selykg wrote:
| This is all part of the FIDO Alliance, so, a standards based
| solution that anyone with the wherewithal to implement it can
| do so. Many password managers have already said they'll be
| supporting it, as well as major vendors (Google and Apple for
| instance).
|
| I'm struggling to see your complaint being a valid one. This is
| basically webauthn, so use a Yubikey or similar device if you
| wish.
| dane-pgp wrote:
| When you say "the FIDO Alliance", you mean the entity that
| runs a Metadata Service[0] which:
|
| > provides organizations deploying FIDO Authentication with a
| centralized and trusted source of information about FIDO
| authenticators.
|
| The aim of this centralized system is to allow revocation of
| hardware that doesn't meet their unchallengeable opinion of
| whether you've spent enough money on your device or not. They
| can similarly require that devices do biometric scanning[1],
| and be issued by your government, and require you to agree to
| lengthy (and self-updating) terms of use.
|
| There are actually (at least) two different types of device
| attestation that FIDO support[2]. One uses a hardcoded on-
| device private key, that's common between 100,000 devices of
| the same model, which means that an attacker can brick 99,999
| other people's devices just by extracting the key from their
| own device. The other method requires a certificate from a
| "trusted third-party Attestation CA", which presumably allows
| a malicious (perhaps government-mandated) CA to spy on (and
| filter) every login request you make.
|
| This system is like a dystopian parody of the traditional
| model of web security, which had no need for "authenticators
| that have a Trusted Platform Module (TPM) onboard", and which
| only required CAs to be on a list that the _user agent_ is in
| control of (and users can add their own CAs to). Instead,
| what FIDO are building is basically DRM for human identity,
| with all the corruption and failure modes that entails.
|
| [0] https://fidoalliance.org/metadata/
|
| [1] https://fidoalliance.org/specs/biometric/requirements/
|
| [2] https://research.kudelskisecurity.com/2020/02/12/fido2-de
| ep-...
| stevewatson301 wrote:
| You'll be out of luck when trying to switch from one
| ecosystem to another (for example, from Apple to Google).
| selykg wrote:
| This is really no different between switching hardware
| devices.
|
| Step 1. Sign in using your existing device
|
| Step 2. Add your new device
|
| Step 3. Remove your old device (or keep it for a backup)
|
| And if you feel that's going to be a big issue for you, use
| a 3rd party software based tool like Bitwarden, 1Password,
| or other tools that have indicated they'll be supporting
| this. That info will sync between those software based
| tools and allow you to use whichever devices you wish,
| across multiple platforms with minimal effort.
| dane-pgp wrote:
| > Step 1. Sign in using your existing device
|
| That's possible, unless you are switching device because
| your previous one broke (or was destroyed/stolen/lost).
|
| I imagine that Apple has very precise data about the
| reasons why (and situations where) people switch from iOS
| to Android, and making that switch as unthinkable as
| possible is part of their user-retention efforts.
| selykg wrote:
| Sure, but here's the deal with this. Even with Yubikeys
| it has always been recommended (as long as I've been
| involved in these types of discussions anyway) that you
| should have two of them. If you lose one you have one
| safely secured that can get you into any service you need
| to.
|
| This is my general stance on it as well, and one that I
| think I would still strongly recommend even in this new
| Passkeys era. That would cover situations where your
| device is damaged and you can't easily turn the old
| device on.
|
| Part of this is solved by these keys being synced on
| each's services, they're synced via iCloud Keychain on
| Apple's side for instance, so you'd just need to get a
| new Apple device, sign into your iCloud account and
| provide the password for iCloud Keychain then you're off
| to the races. But if in the middle of this you opt to
| switch from Apple to Android, you're SOL unless you have
| a backup.
|
| Just my two cents on it, I don't think any of this
| completely solves the need for backups, but for some
| portion of people it probably does, and that's those that
| are unlikely to switch between platforms.
| tjoff wrote:
| > _If you lose one you have one safely secured that can
| get you into any service you need to._
|
| Even that is not good enough, by a longshot. This is so
| much worse than even regular passwords.
|
| It works for corporatiosn. Lost your key? Go to IT and
| generate a new one.
|
| It does not work for individuals.
| greatgib wrote:
| Remember how gmail was just imap/smtp? etc...
| donio wrote:
| Yes, and it still is. I have been using Gmail since 2004
| and I very rarely touch the web or mobile UIs. 99% of my
| interactions with it are through SMTP and IMAP. I don't
| think that Gmail has fundamentally changed in this sense,
| it has just gotten very popular.
|
| The various incarnations of their chat services is a better
| example. Gtalk used to have great XMPP support, even
| federation for a while. All remnants of that are gone now
| so I had to stop using it.
| thrillgore wrote:
| Coming never to Firefox, Edge, and iOS.
| madjam002 wrote:
| It's been supported on iOS since iOS 16
| genpfault wrote:
| > Passkeys on users' phones and computers are backed up and
| synced through the cloud to prevent lockouts in the case of
| device loss.
|
| How do you back them up locally?
| randyrand wrote:
| It seems to be the only question they are unwilling to answer.
|
| Keys for me, but not for thee!
| okhuman wrote:
| Check out AuthCompanion, a passwordless login implementation for
| ideas. https://github.com/authcompanion/authcompanion2
| aseipp wrote:
| Also along these lines, there's a really neat little library
| called "SimpleWebAuthn" that also supports Passkeys, and is
| basically a small dependency-free set of client Javascript (for
| initiating the user flow) and a small JavaScript server
| component to go with it: https://simplewebauthn.dev/
|
| The code is pretty simple and a good place to start, as well as
| AuthCompation, if you wanted to roll your own library in your
| language of choice or whatever, or something very custom. I
| found both useful recently.
| account-5 wrote:
| I don't use my phone to log in to anything. All my stuff is done
| on a computer with a password manager.
|
| At no time am I even likely to rely on Google for anything this
| important; every other week there's a thread about Google killing
| off accounts for no reason. No way would any sane person allow
| Google access to this with their track record. And this isn't
| even considering my suspicion that Google only wants to "help"
| with this so you're locked into their services and they are
| better able to track your activity.
| yalogin wrote:
| Why can't the password manager kill your account? I am not
| advocating for google, just asking about the other solution you
| are relying on.
| erklik wrote:
| I don't think the point is that they can't. Just far more
| unlikely to, and there's usually more recourse. Google is
| mega-corp who never listens to their users, and are un-
| contactable. Some AI can and probably will ban some people
| for no real reason and even Google won't know why it
| happened.
| forty wrote:
| You might be able to do "passkey" with your password manager
| https://www.theverge.com/2022/8/31/23329373/dashlane-passkey...
| (I work for this specific one, but I'm sure others have similar
| things in the work)
| smileybarry wrote:
| AgileBits have passkeys in the works for 1Password:
|
| https://blog.1password.com/1password-is-joining-the-fido-
| all...
| Spivak wrote:
| I mean that's gonna be my adoption path. Once I can store
| passkeys in Bitwarden I'll switch to them everywhere.
| 40four wrote:
| I'm with you, I de-Googled all my services a few years ago, and
| I couldn't be happier with the decision.
|
| I'm curious though, what's preventing you from using a password
| manager on your phone? I use KeePass, and I'm able to use my
| password DB on any device I want.
| kelnos wrote:
| How do you handle syncing? I use KeePassXC on my desktop, and
| I back up the encrypted password DB to SpiderOak, but I
| haven't figured out a good way to get that DB onto my phone,
| auto-synced.
|
| Also are you worried about the security of the DB on your
| phone? My password DB's passphrase is a good 50+ characters
| long, which I can type quickly on my laptop, but I can't
| imagine pecking that out on a phone. And I feel like I would
| not want the DB unencrypted/unlocked all the time on my
| phone; given the possibility of my losing it or it getting
| stolen, I'd want it to re-lock immediately after each use.
| account-5 wrote:
| Nothing really other than it's a device I can loose to easily
| or it could be stolen. I don't do banking on my phone either.
| Plus there's the hassle of syncing it too.
| alyandon wrote:
| Exactly. I will never trust Google to control access to my
| logins knowing that the Sword of Damocles (the Google "AI"
| deciding I'm a bad person) is hanging over my head.
|
| If Google did an about face and started providing reasonable
| escalation mechanisms for when they lock you out of your
| account based on a faulty decision of their algorithm I'd
| consider it.
| KronisLV wrote:
| > I don't use my phone to log in to anything. All my stuff is
| done on a computer with a password manager.
|
| More or less the same, except that I haven't found good TOTP
| solutions for the desktop, to the tune of KeePass (something
| that can run on Windows/*nix instead of making me use something
| like FreeOTP, Google Authenticator or other Android/iOS apps;
| or in addition to the mobile apps).
|
| That said, even with multiple Google accounts for different
| things (e.g. personal e-mails, file storage, cloud services
| etc.) it feels like eventually you might want something like
| Qubes OS, another way to run multiple separate VMs, or just use
| separate devices for separate use cases.
|
| Much like how some orgs have separate laptops for accessing
| prod environments, that are more tightly controlled, even
| though that's not convenient enough for most people.
| Ciantic wrote:
| Depending on your setup you could just generate TOTPs on
| command line and copy to clipboard, that's what I've
| implemented: https://github.com/Ciantic/totper
|
| It works pretty well with pass (password manager) that stores
| each individual entry in GPG encrypted file. GPG is pain, but
| if you happen to use it already then it works.
| SAI_Peregrinus wrote:
| KeePassXC supports TOTP. Right-click a key, TOTP-Set Up
| TOTP... and put in the secret key (and settings if needed).
| saulrh wrote:
| Bitwarden will do TOTP, and its CLI tool is quite usable. If
| you want it fully local, just stand up a docker of their
| server software (which is open source) or the open source
| reimplementation (vaultwarden).
| josteink wrote:
| > Bitwarden will do TOTP
|
| Not disputing this, but it requires a "pro" account which
| is $10 a year.
|
| No big deal to me, in fact I find it a great deal, but I
| think it's fair to be clear about this as not to provide
| false expectations.
| saulrh wrote:
| Fair. And self-hosting an instance in the cloud is
| probably comparable in cost.
| mimi89999 wrote:
| Do you know if it's possible to see a list of stored passkeys in
| Android? I installed the Play Service beta, managed to create a
| passkey and sign in, but can't see the list of credentials
| anywhere in the UI.
| arnarbi wrote:
| There will be, in the password manager settings on Android
| (under Settings, "Passwords & Accounts" and "Google"), but it
| will unfortunately take a couple of more days to roll that out
| to the beta.
___________________________________________________________________
(page generated 2022-10-12 23:00 UTC)