[HN Gopher] Apple Passkey
___________________________________________________________________
Apple Passkey
Author : samwillis
Score : 490 points
Date : 2022-06-06 18:24 UTC (4 hours ago)
(HTM) web link (developer.apple.com)
(TXT) w3m dump (developer.apple.com)
| pronlover723 wrote:
| How does this bode for anonymity and multiple identities?
|
| I'm imagining a world where all PCs/Macs/Smartphones have
| FIDO/WebAuthn and there's no other way to log in. Can I setup up
| multiple IDs on my iPhone and decide which services get to be
| associated with which id? I get that supposedly iPhone (etc) will
| (may?) give out a different number to each service but they'll
| still be associated with a single account at Apple's level.
| Further, it's likely these services will ask for more info and
| Apple will give it to them.
|
| As it is I have a different id for almost every service. I'd like
| to keep it that way.
| psanford wrote:
| FIDO logins are not shared across relying parties (sites), each
| site gets its own (that's what makes FIDO phishing proof). If
| you want a single identity that multiple sites know about
| you'd, login using a third party identity provider where you'd
| use your passkey.
|
| FIDO2 resident keys do support multiple identities for a single
| relying party (site).
| dane-pgp wrote:
| > I'm imagining a world where all PCs/Macs/Smartphones have
| FIDO/WebAuthn and there's no other way to log in.
|
| You won't have to imagine that for long, because that's the
| world we are sprinting towards.
|
| Once practically everyone has accepted and adopted this system,
| governments (having already banned E2EE messaging apps by this
| point) will complain that Big Tech are allowing cyber-
| terrorists to maintain anonymous identities online and not
| doing enough to protect the children.
|
| The offices of Apple, Google, and Microsoft would then receive
| calls from the national tax/anti-trust authorities saying the
| government was thinking of launching an audit/investigation
| into those companies and wouldn't it be a shame if something
| happened to their profit margin that year.
|
| Within a few months we'd see these companies all "voluntarily"
| release software updates which add a "Citizen ID" field to
| every FIDO interaction, with those IDs being issued by a
| government API and verified using a bank card and facial
| recognition.
| LunarCamper wrote:
| Does this explain at least some of the Okta drop in share price?
| babuloseo wrote:
| So they emphasized that this is going to kill "phishing" I doubt
| it.
| hex9893628af wrote:
| What I would like to know is if this takes off, will I finally be
| able to use my Yubikey on all the same sites that suppprt Apple
| Passkey?
| protomyth wrote:
| 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.
| heckyeahs wrote:
| here4funzies wrote:
| If this is about "[hardware devices] for generating and
| authenticating accounts" like WebAuthn FIDO et al what happens
| when I upgrade my Macbook. Do I revert back to password in order
| to associate the new private key (or hardware generate password)
| with my existing account?
| stetrain wrote:
| The keys are synced through iCloud Keychain, presumably also to
| your new Mac.
| sholladay wrote:
| What I want is to use the device password instead of biometrics.
| So the device itself and its TPM are the FIDO authenticator, the
| thing I have in 2FA terms, and the device password is the thing I
| know. Personally, I feel I can better protect a password than my
| fingerprint. But I still want the benefits of 2FA and public key
| crypto where the app/website doesn't receive any sensitive
| information. I'd be okay with pressing a button to prove user
| presence. I'd avoid syncing the keypairs between devices, instead
| enrolling a new keypair for each device. I guess that last part
| could be annoying but it's pretty much how I use SSH today and
| it's not that bad.
| mwcampbell wrote:
| While we're talking about authentication: Once the user is logged
| in, how practical is it for native apps on Apple platforms to use
| something more secure than bearer tokens to authenticate with the
| service on each request? I'm reminded of
| https://mjg59.dreamwidth.org/59704.html
| atonse wrote:
| My wife signed up for calm.com using Sign in with Apple. Thanks
| to this, I am not able to occasionally use her login to listen to
| the wonderful music. There's just no way in hell I'm paying the
| $60 a year or whatever they're asking to listen to a couple songs
| every now and then. In a normal setting, she'd add her login to
| her 1password and I'd be able to use Calm.com, and who knows, I
| would've grown to love it, and gotten myself a second
| subscription.
|
| But since this experience has been so confoundingly annoying,
| Calm.com won't get a penny from me. (Not even sure I want to
| blame them... but rather how it's impossible for my wife to just
| "share" that credential with me even if she wanted to)
|
| Not being able to share a certain type of login (for this kind of
| family sharing scenario) has really soured me on the more
| personal use cases for these technologies, even though they are
| really solid from the tech side.
|
| Like people often say, most products are competing with Word,
| Excel, and email, authentication is competing with me just being
| able to tell a human my username and password.
|
| Again, there are many instances where being able to share these
| credentials seamlessly between non-power users is totally legit.
| When I sit with my dad to help her log in to his patient portal
| to get some medical info. Or when my mom wants help to review her
| Verizon cell phone bill. Or when I get my wife's credentials to
| cancel a hotel reservation.
|
| How are they going to solve the totally legitimate sharing use
| cases? Using PKI actually gives you a wonderful set of tools to
| do this (underlying implementation could be that we generate a
| temp cert that expires in 24 hours, signed by her original
| credential certificate saying it's a shared credential, etc)
|
| I really hope these are the use cases that get more fleshed out
| before these technologies reach mainstream.
| teeray wrote:
| This sounds like exactly the dark pattern Netflix will be
| clamoring for. "Oh gee, looks like you can't share passwords
| anymore..."
| WorldMaker wrote:
| "Sign in with Apple" does have a very bare-bones OIDC flow in
| the browser on non-Apple devices/browsers. That flow takes you
| through a typical Apple Cloud login flow with Apple ID email
| and password and usual 2FA if it's the first time on that
| browser/device.
|
| To meet bare minimum requirements sites like Calm.com often
| only show the "Sign In with Apple" button for iOS and iPadOS
| user agents. You can sometimes fake an iOS/iPadOS user agent
| and get the buttons to show up and then switch the User Agent
| back to get the boring in-browser OIDC flow.
|
| As an iOS/iPadOS but Windows PC user I find it frustrating how
| many websites intentionally hide that button in other browsers,
| just when dealing with my own accounts.
|
| I feel like Apple could maybe do a better job of education
| here: "please don't hide the button on non-iOS/iPadOS user
| agents". I hope Apple has strong developer education plans for
| Passkey.
| neill wrote:
| For a business, implementing FIDO in this case seems like a
| win. They get more lockout of password sharing, and have to
| explicitly work to enable shared logins (if that's something
| they want). Of course it's nice for an end user to be able to
| share credentials, but I think long term outlook will be
| towards businesses and applications pushing to improve their
| user management tooling.
|
| Anecdotally, in the instance you described they net the same
| $60/yr regardless of wether you use your wife's login, so
| they're getting more stringent access controls (though you
| could always use the device in question, too) in line with
| their terms of service.
|
| (Would also note that my response does not cover your latter
| points on helping users manage their accounts with their
| presence, but without their device presence, which I agree is a
| valid concern)
| lsaferite wrote:
| You also ignored the point that perhaps they'd have gotten to
| like the service enough to get a subscription for themselves,
| but refusing out of spite now.
| biztos wrote:
| Is that not a use-case for Family Sharing?
|
| Apple says you can "download content" bought by other family
| members[0], but I guess this doesn't work for subscriptions?
|
| That's a real missed opportunity. I would expect them to at
| least allow the app developer to opt in to sharing. Selling two
| licenses into a household has to be pretty rare, whereas having
| happy-family customers is great word of mouth. "My wife uses
| FooApp and now I use it too!"
|
| [0]: https://support.apple.com/en-us/HT201085
| Someone1234 wrote:
| Most IAPs and non-Apple subscriptions don't work with Family
| Sharing, and the few that do there's no way to tell before
| you buy.
|
| Family Sharing is set up in such a way that you're punished
| for creating child Apple accounts as Apple recommends,
| because you'll need to repurchase MOST IAPs several times
| over.
|
| Apple's subscriptions are the exception rather than the rule,
| but they like to promote it in such a way as you'd think all
| Subscriptions/IAPs are shared when they're not.
| zippergz wrote:
| The app developer has to specifically support Family Sharing
| if they want to allow people to share subscriptions.
| [deleted]
| ZetaZero wrote:
| > How are they going to solve the totally legitimate sharing
| use cases?
|
| According to their Terms, there are no legitimate sharing use
| cases. "You agree that you won't disclose your Account password
| to anyone". That said, Calm has a family plan (6 users) for
| only $30/year more.
| zxcvgm wrote:
| This is based on the open standards WebAuthn and FIDO2, where the
| credentials ("passkeys") are synced via iCloud Keychain.
| Currently you need remember to register at least 2 security keys,
| in case one is lost/misplaced. The syncing of passkeys in iCloud
| solves this backup problem.
|
| https://fidoalliance.org/apple-google-and-microsoft-commit-t...
| Vladimof wrote:
| > The syncing of passkeys in iCloud solves this backup problem.
|
| But then apple has your keys....
| om2 wrote:
| It's end to end encrypted. Apple doesn't have access.
| jtokoph wrote:
| I would assume that they are at least encrypted locally
| before being uploaded to iCloud. (But yes, Apple could always
| change things)
| SamuelAdams wrote:
| Don't be so certain - we need more details from Apple on
| this. Last I checked iMessage was still (!) not encrypted
| when backed up to iCloud.
|
| https://www.howtogeek.com/710509/apples-imessage-is-
| secure.....
| 0xCMP wrote:
| iCloud Backups != iCloud syncing iiuc. Passwords/Wifi/etc.
| syncing is a different E2EE system.
|
| You can disable iCloud Backups and still use iCloud
| Vladimof wrote:
| ahhh so they already have what they need to do iCloud E2EE,
| they just decide not to use it for your data....
| kccqzy wrote:
| Yup. Probably because law enforcement would be livid if
| Apple did that. In the San Bernardino terrorist case,
| Apple basically said triggering an iCloud backup is the
| best way to get the contents of a locked iPhone. Apple
| routinely supplies law enforcement with contents of
| iCloud backup.
| sircastor wrote:
| It remains one of the clearest examples of law
| enforcement wanting a friction-free solution for getting
| data out of iOS without Apple. They could have easily
| attained the information and have been doing so for
| years. They were explicitly trying to generate sympathy
| towards a backdoor solution.
|
| What's sort of surprising to me is how much they
| overestimated public support for their cause.
| samwillis wrote:
| E2EE would have made it significantly harder for Apple to
| build the web based apps at iCloud.com. Not to say that
| shouldn't have though, but I can understand whey they
| didn't.
| plonk wrote:
| Does anyone use that? It's nice to have when I want to
| access my data from the web, which is never, and it's not
| worth the loss of security.
|
| But I imagine the FBU wouldn't like an end-to-end
| encrypted iCloud Photos at all.
| mtgx wrote:
| Yes, this is known:
|
| https://www.reuters.com/article/us-apple-fbi-icloud-
| exclusiv...
| luhn wrote:
| iCloud Keychain is end-to-end encrypted.
| gpanders wrote:
| Passwords in iCloud Keychain are already E2EE, it seems
| reasonable the private passkeys would be too.
| djbusby wrote:
| How could one verify that? like for compliance audit?
| fnordpiglet wrote:
| https://support.apple.com/guide/sccc/introduction-
| sccccea618...
|
| Introduction to Apple security assurance
|
| As part of our commitment to security, Apple regularly
| engages with third-party organizations to certify and
| attest to the security of Apple's hardware, software, and
| services. These internationally recognized organizations
| provide Apple with certifications that align with each
| major operating system release. ...
| znpy wrote:
| Are such third parties listed? Can you inspect their
| reports? What testing methodologies are involved in order
| to issue such certifications? And can we see such
| certifications at all?
| ccouzens wrote:
| > iCloud ... backup
|
| > E2EE
|
| If you can lose all your existing devices, and can still
| restore your data, then that data isn't end to end
| encrypted.
|
| I'm taking the "end" in e2ee to mean your devices. Nothing
| but your devices can decrypt your e2ee prospected data. If
| a new device can enter the circle of trust without an
| existing device's corporation then there is a backdoor.
|
| I imagine icloud keychain supports synchronization rather
| than backup
| systemz wrote:
| Maybe usage of user account password would allow for E2E
| without any device?
| hoorible wrote:
| The password stored in your backup via iCloud Keychain
| use the passcode of your devices as a secondary
| encryption/lock method, which doesn't have a password
| recovery mechanism like the Apple ID used to secure your
| iCloud backup. Not sure that meets the definition of E2EE
| but it's not like the passwords are recoverable by
| another party (or even you, if you forget the passcode)
| just because they're in your iCloud backup.
| gsibble wrote:
| How will this work on Linux?
| psanford wrote:
| FIDO usb devices just use the HID protocol so they work fine
| on linux. Chrome and Firefox both support them.
|
| I wrote a FIDO implementation that protects the signing key
| using the system's TPM specifically for linux:
| https://github.com/psanford/tpm-fido
|
| There is no reason why you couldn't implement a similar
| syncing strategy in a tool like this if you wanted to.
| tialaramex wrote:
| > just use the HID protocol
|
| This is literally true, and covers what was important in
| context, but warrants a little extra explanation. Since
| these devices are specifically for humans to interface with
| (they typically have a button or contact sensor, though
| some have keypads or a fingerprint reader) they are
| logically Human Interface Device class USB devices, but
| they do _not_ speak the HID Keyboard or Pointing Device
| sub-protocols like your mouse or keyboard (or the built-in
| "take a photo" button on your web cam). Instead they
| provide a FIDO-specific HID sub-protocol, which is publicly
| documented, instead of operations like "Caps Lock pressed"
| it's got stuff like "Begin enrolment" or "PIN xxxx entered
| by the user" which only makes sense for this specific
| problem.
| balena wrote:
| Isn't this approach significantly less secure than Apple's
| though? As far as I understand the secure enclave
| coprocessor in Apple devices stores key material _and_
| implements user verification (TouchID etc.), right? Instead
| software like tpm-fido bridges (in software) a user
| verification mechanism (maybe even a fingerprint reader)
| and the system 's TPM. But such a system can be interposed
| with mere root access, and the TPM tricked in giving out
| its secrets, no? Please correct me if I'm getting it wrong,
| but Apple's approach is instead resistant even to full
| kernel compromise, precisely because the communication
| between TouchID/FaceID and the secure enclave cannot be
| interposed.
|
| I'm a tpm-fido user myself by the way, thank you psanford!
| psanford wrote:
| Yes, having the verification done by the secure enclave
| itself is more secure. The TPM spec does allow for direct
| integration with biometric devices, but I'm not aware of
| any general purpose computers that ship in this
| configuration.
|
| > TPM tricked in giving out its secrets
|
| To be clear, the key can never leave the TPM (with how
| tpm-fido is implemented). The threat is an attacker can
| perform an online attack by getting the TPM to sign
| messages it shouldn't. But you couldn't steal the key
| from the TPM and use it somewhere else.
|
| But it doesn't really matter for the Webauthn threat
| model. An attacker with root access can steal your
| browser sessions directly.
| al_borland wrote:
| >Currently you need remember to register at least 2 security
| keys, in case one is lost/misplaced.
|
| This is always my issue with 2FA or passwordless auth. You're
| forced to have 2 devices and are kind of screwed if you don't
| hvae two on you.
|
| I was on a trip and broke my iPhone. It had my plane tickets on
| it to get home. I was able to get a replacement from Apple,
| they just gave it to me and sent me on my way. When I turned it
| on it wanted me to authenticate with one of my other Apple
| devices. By dumb luck I happened to have my iPad with me. If I
| didn't have that, I'm not sure what I would have done.
|
| A co-worker told me to move all my 2FA to Authy as a means to
| avoid locking 2FA to hardware, but I haven't sufficently looked
| into it yet.
|
| While I don't like passwords and understand their very real
| security limitations. I'm also not a fan of my phone becoming
| my identity.
| nicoburns wrote:
| Password managers like Bitwarden can do TOTP with syncing.
| Doesn't help with Apple though which uses non-standard 2FA. I
| actually have some accounts using SMS still, because I can
| fairly easily get a replacement sim if the device is lost.
| hoorible wrote:
| Apple's implementation uses SMS as a backup. Thinking is
| probably that if you only have one device, it's usually your
| phone; so you would have been able get your 2FA code via
| text. It's not easily discoverable though, so easy for you to
| miss it.
| chrishas35 wrote:
| > Apple's implementation uses SMS as a backup.
|
| I hope they'll go away from this, or at least give the
| option. I won't use their password/key storage until they
| do. 2FA is only as good as the weakest link, and SMS is the
| weakest possibility.
| whoisjohnkid wrote:
| Woah this is awesome. Does anyone know if this is using web authn
| under the hood? Or is this a new spec? Would love to see Pub/Priv
| replace passwords
| aseipp wrote:
| Yes, it uses WebAuthn under the hood. Passkeys have technically
| been available to developers for a while I think but very
| experimental still. I guess they've begun hitting new
| milestones.
|
| This is basically the biggest problem with WebAuthn today: the
| credentials are tied to the browser -- or really whatever
| application is using WebAuthn, browser or not, name aside --
| which means that if you register for a service with Firefox,
| you have to re-register with Chrome. If the service is designed
| for it, it might associate multiple public keys to a single
| "user." So Passkeys are just a pretty natural combination of
| two things to fix that: "WebAuthn keys, but inside iCloud
| Keychain." Presumably any apps that integrate with iCloud
| Keychain can then use them as expected.
|
| Of course you can just export the key material, which in a
| sense is "all" Passkeys are doing: they're a formalization of
| how to export and manage those keys in keychain.
|
| But there are still some major issues:
|
| - Enrolling new devices from old ones. This is especially
| tricky for platform authenticators. For example I register for
| a website using FaceID on my iPhone, which uses the "platform"
| authenticator rather than the "cross-platform" authenticator,
| and now I need to now enroll my Macbook and Windows desktop.
| They both need _new_ keypairs, because the original account is
| using a platform authenticator. And the new keypairs might be
| either platform or cross-platform authenticators. This is
| especially prevalent on browsers (apps can work around it with
| a more specific scheme; see below.)
|
| - Similarly: cross-platform software for sharing or syncing
| credentials. Something like 1password but with WebAuthn support
| for handling those cross-platform webauthn keys.
|
| Both of those require a lot of software and decision making to
| get it all working correctly, both on the side of operators and
| clients. For example, in your own application (not a browser),
| you could simply use a platform authenticator like FaceID to
| read a cross-platform WebAuthn credential from iCloud Keychain,
| which would avert part of problem 1. But in a browser, mac or
| iphone users would probably _like_ to use FaceID /TouchID,
| which are only available as a platform authenticator, so you'd
| have to handle that case of new enrollment.
|
| There are also a million other issues, for example Windows
| Hello has like a million weird edge cases for how it works in
| and outside of the browser. macOS seems to be the furthest
| ahead here with the introduction of Passkeys, and the strong
| system-wide support for TouchID/FaceID/etc. I do not know what
| the state of Linux is; presumably you could integrate this with
| something like gnome-keyring but there's no synchronization
| service either.
|
| So we're still a ways away from actually eliminating passwords.
| WebAuthn works today but does need a lot of extra oil to make
| it smooth, and it's still not a primary authentication
| mechanism unless you're very careful about your userbase. But
| Passkeys are a good start and will mean you'll need passwords
| in less apps, and you'll be able to log in securely more
| quickly. It's a small but needed step.
| tialaramex wrote:
| > This is basically the biggest problem with WebAuthn today:
| the credentials are tied to the browser
|
| That's definitely not true. My Feitian ePass for example
| (very cheap USB dongle that lives with my house keys) works
| just fine to sign me into GitHub on this desktop PC w/
| Firefox on Linux, it works fine via a USB-C to USB-A adaptor
| to sign in on my Android phone w/ Chrome, and likewise on the
| Windows laptop I use for work when I needed to access my
| personal site briefly at Christmas and that was the only
| laptop I'd brought with me.
|
| If you have credentials tied up in some proprietary system
| then, yeah, they're trapped in there, and in Apple's case
| they've decided to make it possible to move the credentials
| to another Apple device via iCloud.
| floatboth wrote:
| Yeah, since Apple's (and Google's) soft WebAuthn
| implementation is designed for syncing across devices, it
| should also work with many browsers on the same machine.
| 0x0 wrote:
| Is this the return of the html tag <keygen> ?
| tgsovlerkhgsel wrote:
| Hopefully this will be compatible with WebAuthN in practice and
| encourage web sites to implement it (in a compatible manner). It
| often does take Apple's heft to force a change across the web.
|
| Most importantly, hopefully web sites will implement support for
| multiple authenticators, so you can actually use this safely
| without relying on a cloud-synced solution.
|
| I hope this pushes out other, less secure and more tedious 2FA
| methods. However, once it becomes popular, sign in with WebAuthN
| only will likely not be enough, as attackers learn to attack it
| (e.g. stealing software-based tokens, adding a cloud-synced
| device, hijacking already-authenticated sessions from compromised
| machines)
| paxys wrote:
| What standard is this using? The doc doesn't specify.
| SEJeff wrote:
| Under the covers, this is webauthn, which is based on
| FIDO2/U2F. I knew it was webauthn as soon as I read "relying
| party" and the two keypairs.
| samwillis wrote:
| According to the WWDC Keynote they are working with the FIDO
| Alliance on it: https://fidoalliance.org/
| scottlu2 wrote:
| Comment from the presentation: "Worked with fido alliance to
| work across platforms".
| EtienneK wrote:
| FIDO2/WebAuthN
| saos wrote:
| How does this impact 1Password going forward?
| stetrain wrote:
| 1Password is also part of FIDO. I assume if you want to use
| 1Password on Apple devices to store passkeys that should work
| fine, just like it does for passwords today.
|
| https://blog.1password.com/1password-is-joining-the-fido-all...
| Rafert wrote:
| They've already put this WebAuthn teaser up:
| https://www.youtube.com/watch?v=lYFxfchhR1g
| [deleted]
| elamje wrote:
| A more generalized solution: https://passage.id
| hackererror404 wrote:
| What happens if you lose your device or it breaks or something?
| Do you lose access to anything tied to it?
| babypuncher wrote:
| It sounds like your private keys are stored in iCloud, so they
| should be accessible on a new device as long as you remember
| your Apple ID, password, the device-specific PIN/passcode from
| your old phone.
| FollowingTheDao wrote:
| I would guess you could not sign into it on another computer,
| right?
|
| They must have considered this because that's would be a huge
| hassle.
| xmdx wrote:
| They said in the event that everything is synced on iCloud so
| all your devices can use the keys, which makes me think no,
| it's just a password manager, without the password bit. Maybe
| they create a separate key for each device, but then why
| mention iCloud syncing at all.
| howinteresting wrote:
| It's a password manager _with cryptographic vendor lockin_.
|
| There are definitely some benefits though, such as immunity
| from phishing. Surely we as the industry can bring them about
| in a way that doesn't involve cryptographic vendor lockin.
| vorpalhex wrote:
| The secrets can be exported - whether or not they will
| allow that though...
| altairprime wrote:
| The industry doesn't seem to have a working software
| solution for mobile phone authentication secrets that both
| is 1) immune to persuading a user to export their data (to
| get phished), and 2) allows a user to export their data at
| any time (to prevent lock-in).
|
| What would it look like to do #2 safely, without enabling
| the phishing that we see today with #1?
| danShumway wrote:
| I get where you're coming from and you're not wrong, but
| at the same time, I don't buy this as an excuse for
| vendor lock-in here, because it seems like Apple is
| already backing up passkeys to iCloud.
|
| If Apple has decided that the risk of getting your
| passkeys phished out of your Apple iCloud Account is
| outweighed by the benefit of users being able to
| restore/sync login details immediately when they buy a
| new iOS device and log into it, then I think it's
| reasonable for users to expect the same treatment and the
| same experience when they're moving away from iOS.
|
| If Apple wasn't backing up any of the logins, and they
| had committed to when you trade in your phone and upgrade
| to the latest iPhone forcing you to manually re-create
| all of those keys one-by-one using your recovery option,
| then I'd accept not having an export option for
| Android/Linux/Windows. Otherwise, it will just seem
| really suspiciously convenient to me if they ultimately
| decide that exporting keys is acceptable risk _unless_ it
| 's to a competitor's device.
|
| As far as I can tell, there hasn't been any official
| confirmation that users won't be able to export them to
| non-iOS devices, so maybe it's all worry over nothing.
| But I don't think security is a justification to apply
| restrictions specifically only on devices outside of
| Apple's ecosystem.
| snowwrestler wrote:
| I think Apple encrypts the pass keys locally on your device,
| then stores encrypted copies in iCloud, which you can download
| and decrypt on a new device.
|
| On the new device you would be prompted for the passcode of the
| device you lost or broke, to decrypt and access them.
| gzer0 wrote:
| iCloud (and anything on iCloud) is _explicitly_ not
| encrypted, though [1].
|
| [1] https://www.reuters.com/article/us-apple-fbi-icloud-
| exclusiv...
| macintux wrote:
| That's not universally true.
|
| https://support.apple.com/en-us/HT202303
|
| > If you forget your password or device passcode, iCloud
| Data Recovery Service can help you decrypt your data so you
| can regain access to your photos, notes, documents, device
| backups, and more. Data types that are protected by end-to-
| end encryption--such as your Keychain, Messages, Screen
| Time, and Health data--are not accessible via iCloud Data
| Recovery Service.
| ddoolin wrote:
| Literally in the article:
|
| > Instead of protecting all of iCloud with end-to-end
| encryption, Apple has shifted to focus on protecting some
| of the most sensitive user information, such as saved
| passwords and health data.
|
| > But backed-up contact information and texts from
| iMessage, WhatsApp and other encrypted services remain
| available to Apple employees and authorities.
| vngzs wrote:
| This is false; some data is end-to-end encrypted, including
| Health and Keychain data. Photos, contacts, and Drive are
| "encrypted on server" which means Apple can read them.
|
| https://support.apple.com/en-us/HT202303
| [deleted]
| kennywinker wrote:
| That's iCloud backups, not everything icloud. iCloud
| Keychain is encrypted (https://support.apple.com/en-
| gb/guide/security/secdeb202947/...) tho I'mnot sure I trust
| their escrow system to not escrow data to the gov if asked.
| theshrike79 wrote:
| Photos need to be encrypted on server so they can be
| scanned for CSAM. Apple tried to move that bit to the phone
| so they could encrypt photos on server too, but we all know
| how that went.
| colburnmh wrote:
| Data in iCloud is going to be encrypted by the host
| provider in-transit and at rest. That is not the same as
| being encrypted at the source by Apple. It means that
| Google, Amazon, Azure (and whatever other platforms Apple
| uses for iCloud storage) will be doing that encryption with
| keys that they have for Apple. All the major vendors have
| storage encryption both in-transit and at rest. I suspect
| that it would be a requirement from Apple for any future
| vendor, too.
|
| It does mean that the data is not sitting in clear-text
| form on the provider's disks. But the exact details of that
| encryption may vary from provider to provider.
| gruez wrote:
| Same thing that happens if your FIDO/U2F key breaks. If you
| have a backup key (or in the case of this implementation,
| icloud backup), then it shouldn't matter. Otherwise you're at
| the mercy of the site that's requesting the credentials. They
| might allow you to authenticate via another method (security
| questions?), or lock you out permanently.
| toomuchtodo wrote:
| Ideally, if you can't identity proof in person, recovery flow
| should be Stripe Identity or another proofing system that
| will consume government ID and output pass or fail. It's the
| next best thing to showing up in person and having a human
| proof you, and saying "oops keys all gone" isn't going to fly
| for the masses at scale.
| blktiger wrote:
| It's tied to a key stored in your iCloud. So basically as long
| as you have a device tied to your iCloud you can get in.
| Presumably, if you lose access to iCloud you will have
| problems.
| willis936 wrote:
| Apple is the face on the screen. There is no lady with a
| hammer.
|
| https://youtu.be/OYecfV3ubP8
| threeseed wrote:
| This is based on an open standard and is entirely optional.
|
| So your analogy makes absolutely no sense.
| willis936 wrote:
| It's a metaphor.
|
| Semantics aside, holding private keys hostage with no
| recourse is Orwellian. A for-profit company has no
| business being a centralized identity authority.
| cokeandpepsi wrote:
| What happens when you're not using an apple device?
| MBCook wrote:
| I saw a screenshot. Somehow a QR code is presented and you
| scan that with your phone. I'm not entirely sure what
| happens from there.
|
| But there was a picture of them using it with a Windows
| machine. So they've thought of it.
| cokeandpepsi wrote:
| interesting, but it still needs an iPhone> -- I was kind
| of burned hard when trying to migrate my iCloud keychain
| passwords to something else so I'm curious how smooth it
| actually is
| [deleted]
| whiteboardr wrote:
| For context: https://arstechnica.com/information-
| technology/2022/05/how-a...
| systemvoltage wrote:
| > available to the masses in the form of a standard adopted by
| Apple, Google, and Microsoft that allows for cross-platform and
| cross-service passkeys.
|
| Any way to use this standard if you're not
| Apple/Google/Microsoft? I'd prefer an option that
| Apple/Google/Microsoft can call a service (that I control and
| authorize). I want to be able to self host such a service or
| have an open marketplace that can compete to serve this
| service.
| dane-pgp wrote:
| danieldk wrote:
| Beta support for Passkey is already in the current macOS/iOS
| releases:
|
| https://developer.apple.com/documentation/authenticationserv...
|
| I am already using Passkeys on some websites.
| samwillis wrote:
| Yes, it looks like it's been around for a couple of months,
| after a somewhat quiet announcement. It's the first I had heard
| of it though.
| jackson1442 wrote:
| Since Fall 2019 actually! (at least that's when I first used
| it)
| danieldk wrote:
| There was a WWDC session last year about Passkey:
|
| https://developer.apple.com/videos/play/wwdc2021/10106/
| firloop wrote:
| Yup, I think the bigger announcement today is around it
| becoming available on non-Apple devices.
| kingcharles wrote:
| Can you use this without biometrics? I don't use biometrics
| because they are not protected by the Fifth Amendment in the USA.
| jjcm wrote:
| They also demoed this working directly in Safari - does anyone
| know how to support this in languages other than swift/obj-c? Can
| this be done with js?
| floatboth wrote:
| As an RP, there is nothing Apple specific for you to do, just
| WebAuthn.
| howinteresting wrote:
| Importantly, if you switch platforms you lose all your auth
| tokens and have to reauth everywhere. It ultimately is yet
| another way to do vendor lockin, except it has the FIDO
| alliance's blessing this time.
|
| The competition, password managers like 1password and bitwarden,
| do not have any sort of vendor lockin. You can freely export your
| passwords from one manager and into another.
| FollowingTheDao wrote:
| Oh, I see now. Don't think I will be using it.
| teeray wrote:
| Plus, password managers have fantastic backwards compatibility
| even on old, crufty sites that will never be updated.
|
| We really should be working to allow better, standardized
| integration with password managers (communicating password
| length and alphabet requirements, well-known URIs to do zero-
| touch credential rotation, etc.) rather than trying to do "Log
| in with BIGCORP" in another way.
| realityking wrote:
| There are some efforts to make things easier for password
| manager. E.g. differentiation new password, old password and
| 2FA token fields: https://developer.apple.com/documentation/s
| ecurity/password_...
|
| I believe some password managers also look at the regex
| attribute to understand required or disallowed characters.
|
| For resetting passwords there's at least a way to deep link
| to the right page: https://web.dev/change-password-url/
| Apocryphon wrote:
| As a long-time Safari user who uses keychain heavily in lieu of
| 1Password or other managers, I probably will migrate to using
| Passkey because it sounds pretty seamless.
|
| But the lock-in point seems like a founded critique. Does
| anyone disagree with this claim?
| michael1999 wrote:
| I'm not sure this is any more locked in then the parent post
| is locked into 1password. Moving auth tools is a pain.
|
| Anyone implementing FIDO should allow you to enrol multiple
| devices. As long as the auth consumers allow multiple keys,
| there's no lock-in. You just need to setup your new device
| before ditching apple.
| howinteresting wrote:
| Moving auth tools is actually quite simple. I migrated from
| lastpass to 1password a few years ago and it was very
| straightforward.
| vorpalhex wrote:
| 1Password et al offer many export options including very
| simple csv
| e_y_ wrote:
| Looking at how various places do 2FA, it's likely that at
| least some websites will _not_ support multiple keys even
| if they ought to.
|
| Also, I imagine that many people do not have the luxury of
| multiple devices. So if you lose your phone, you'll need to
| buy or at least borrow another iOS device to recover it
| from iCloud before you could switch to Android.
| mwcampbell wrote:
| How common would it be for someone who has just lost
| their phone to want to immediately switch platforms?
| Isn't it much more likely that they'd want a new device
| on the same platform as the one they just lost?
| Trollmann wrote:
| Supply chain issues, sanctions, travel or prices you
| can't afford at the moment your phone breaks down may
| make you switch the platform involuntarily.
| sokoloff wrote:
| If they were already planning to switch platforms, the
| loss or destruction of their old device provides a
| natural moment to make the switch, where buying a new
| device feels like it's locking yourself in for another
| couple of years.
| derefr wrote:
| If you can extract tokens from a device, then they're basically
| passwords, not tokens -- i.e. anyone who can hack your device
| can get them. Tokens only add multi-factor security insofar as
| they have distinct exfiltration requirements from passwords.
|
| Services that properly support MFA should simply support
| accounts having multiple bound authenticator devices, each with
| their own private key/seed. In such setups, the proper way to
| rotate out an authenticator device is to add a new device
| first, and _then_ remove the old device; and the proper way to
| protect against a lost device, is to keep an extra bound device
| in safe cold storage somewhere (e.g. a safe deposit box.)
|
| Basically, look at how the crypto people handle the "hardware
| wallets" (really, smart cards) they use for multisig
| transactions. 2-of-3 confirmations, two hot smart cards held
| independently by company officers, one cold smart card held by
| e.g. the company's law firm.
| howinteresting wrote:
| Your first paragraph, restated, is that passwords are
| superior to tokens.
|
| Your "proper way" is absurd and nonsensical for the vast
| majority of users. The first time they get burned by this is
| the last time they'd rely on anything but the one memorized
| password they reuse everywhere.
| derefr wrote:
| MFA itself is absurd and nonsensical for the vast majority
| of users. It's security theatre unless you do it right, and
| if you're doing it right, it's -- as you've said -- too
| hard for most people to bother. Properly implemented, MFA
| is an Enterprise feature, not a personal feature. Like SAML
| SSO, or having audit-log APIs.
|
| The point of setting up MFA is to secure things that really
| _need_ to be secure, where the person with the data is
| aware of real attacker threat-profiles that have real
| interest in their data. It 's a thing that companies that
| hire CISOs care about.
|
| Any implementation of MFA you see in the wild is either
| part of a product that has an enterprise tier that has
| customers like that, where the product devs decided to
| "trickle down" the feature [in a less-secure, but possibly
| _optionally_ secure, form] to lower plan tiers; or it 's a
| cargo-cult reimplementation where a company "saw other
| companies doing it and it seemed like a good idea" -- but
| they exchanged actual security for convenience.
|
| (You can usually distinguish one from the other, because
| the companies "actually doing MFA" will almost always
| support smart-card authenticators -- and have for decades,
| back since doing so required a Java applet. Because
| "issuing each employee a smart card" is what companies that
| actually care about cybersecurity -- e.g. defense
| contractors, investment banks, etc. -- do as a matter of
| course.)
| howinteresting wrote:
| ????
|
| The goal of all this is to make auth tokens be _single-
| factor_ , not one factor in MFA. If you read the Ars
| article linked elsewhere in the thread the people behind
| it are pretty clear about their desire to get rid of
| passwords.
| derefr wrote:
| The security of these tokens is still MFA as an _end-to-
| end security model_ , insofar as you need a something-
| you-know [password, passcode] to _unlock_ the device that
| serves as your something-you-have. So someone who just
| steals the device, can 't use it to authenticate as you.
| (See also: smart cards having PINs.)
|
| And, once again, companies doing MFA _properly_ , enforce
| MDM policies on such devices, such that they either don't
| allow you to use the convenience biometric unlock
| features, or they limit them to ~1 minute before you must
| unlock with a something-you-know factor again.
|
| (I worked for IBM for a year-or-so a while back; they
| required this even for phones not serving as MFA
| authenticators, because they had a threat model that
| included attackers cloning your fingerprint just to snoop
| company secrets out of the emails on your phone.)
| drxzcl wrote:
| closeparen wrote:
| As far as I understand, the story is: casual users don't
| choose unique passwords. MFA, even in its weakest forms
| like SMS, defends against credential stuffing.
| Indiscriminate credential stuffing attacks based on
| database dumps, etc. are common enough that this is
| worthwhile. FIDO/WebAuthn add protection against phishing
| (because the token is bound to the domain name). Phishing
| is also a common indiscriminate attack against casual
| users.
|
| In a world where people used password managers correctly
| and all the time, this might be redundant, but we don't
| live in that world.
| epaulson wrote:
| I can be onboard with this if Apple opens up an iCloud API for
| syncing, so I can sync a non-Apple device through iCloud, and if
| I leave Apple and iCloud behind, my non-Apple devices keep
| working, even if I never sync through iCloud again.
| mceachen wrote:
| C'mon. Non-Apple devices aren't _even remotely_ a priority for
| them. Just look how bad Apple Music is on Android and web.
| shralpmeister wrote:
| The AppleTV app on my LG TV is the best third party app on
| it, IMO. Looks and works great.
| corrral wrote:
| Their Roku and AndroidTV apps are also good. I'm not sure
| I've ever even used the service on a piece of Apple
| hardware, and it's never been a problem.
| nobodywasishere wrote:
| Apple Music on Android is actually really good, I use it
| daily. On some level it was a priority for them for market
| share, to compete with Spotify. I don't see the "competitor"
| in this space (cloud) though that would drive that necessity.
| eddieroger wrote:
| I'm going to sound like an Apple apologize, but what's wrong
| with Apple Music on the web? I just launched it (for the
| second time in a while), and after signing in, was presented
| with a familiar looking UI and all my playlists, and was
| playing searched-for music in under a minute. I know Apple
| prioritizes their platforms first, but this doesn't seem like
| an example of Apple failing a competing platform.
| stetrain wrote:
| Why not just use 1Password or a similar service?
| dyml wrote:
| This is wonderful news! If anyone is interested in experimenting
| we built an API that makes it very simple to add WebAuthn
| (passkeys) to your existing web app.
|
| It's available at https://passwordless.dev
|
| Note: We also maintain the open source fido2-net-lib, the API
| just lowers the friction for devs.
| smorks wrote:
| i use fido2-net-lib for a personal auth site, it works great!
| thanks for all your work!
| largehotcoffee wrote:
| Thank god the touchbar continues to disappear
| [deleted]
| [deleted]
| throwaway92394 wrote:
| Does anyone know how this/FIDO/Webauthn affect privacy? How well
| supported are alt accounts? Are they easy to tell they're from
| the same signer?
|
| I figure privacy is fine as long as the implementations allow you
| to select which account to login with. Is this currently a thing?
| From everything I read it seems like the current implementations
| are only meant to support one identity?
|
| EDIT: These are great responses, also curious if anyone is aware
| if Apple's current implementation supports multiple identities?
| blamestross wrote:
| FIDO/WebauthN are generally "the good guys" when it comes to
| privacy bc "bring your own secure hardware key" is always an
| option. I'm kinda torn over the "use your cellphone as a key"
| approaches as not privacy friendly but we can't actually
| prevent them (you can always simulate a key).
| dane-pgp wrote:
| > you can always simulate a key
|
| But you can't simulate an attestation that you're using a
| device from one of the "approved" manufacturers in the
| cartel. This is basically DRM for human identity.
|
| https://nitter.net/sleevi_/status/1392903827712512001
| jtcasper wrote:
| FIDO2/WebAuthn don't have anything to do with user management
| from an application architecture perspective. They leave all
| the work of combining the attestation credentials and your
| application's concept of a "user" to the application.
|
| This means you can (and should as a designer) have multiple
| sets of credentials for one "user", multiple distinct
| credentials that you (the user) can register to multiple
| separate "user"s in the application, etc.
|
| I believe all FIDO2 authenticators (like hardware keys) should
| generate a new hardware / key ID for each request for pairing a
| new credential. I know that my key does that, when I was
| working on implementing WebAuthn for $DAYJOB.
|
| https://developers.yubico.com/WebAuthn/ is a good jumping off
| point.
| psanford wrote:
| FIDO2 resident keys (the thing people are now calling passkeys)
| allow for multiple credentials for a single site. If you have a
| device that supports resident keys you can try this for
| yourself on https://webauthn.io.
|
| There is also no way for a site to know if two sets of
| credentials belong to the same physical hardware device or not.
| Sites can request the attestation certificate, but that is not
| unique per device (the spec says the attestation cert should be
| shared by at least 100,000 devices). If you want to see the
| attestation cert for a fido(2) device, I made a little tool
| that will show it to you: https://what-the-fido.sanford.io/
| jeroenhd wrote:
| The page doesn't state it explicitly; is this Apple's
| implementation for FIDO2?
| jdminhbg wrote:
| The video presentation said it was part of the FIDO standard.
| jeroenhd wrote:
| Ah, okay. I'm not interested in Apple's periodic product ads
| so I didn't really understand why this was linked again,
| especially since it's been available for a while now.
| MBCook wrote:
| It's been available in beta/nightly form for a little
| while, I think.
|
| But at todays WWDC presentation they announced it as an
| official complete feature for the next releases of their
| OSes.
|
| (That's why there is so much Apple stuff, presentation just
| eneed about 15m ago)
| threeseed wrote:
| It is linked because it was covered in the keynote.
|
| And what is new is that it looks to become a widely
| supported FIDO standard i.e. Google/Microsoft are onboard
| whereas before it was an iOS/macOS only technology.
| jeroenhd wrote:
| Their announcement last month already indicated that it
| would become widely supported Soon (TM):
| https://www.apple.com/newsroom/2022/05/apple-google-and-
| micr...
|
| I'm sort of expecting Google to follow suit with the next
| Android release, and perhaps Microsoft after that when
| the next iteration of Windows 11 drops (or at the same
| time, as Microsoft doesn't have a mobile market and
| relies on Android and iOS integrations).
| gumby wrote:
| Can I use a password manager like 1password it's FIDO2 the way I
| currently can in iOS/macOS? iCloud Keychain is the most barebones
| of password manager
| stetrain wrote:
| Seems like this will be possible:
| https://blog.1password.com/1password-is-joining-the-fido-all...
| gumby wrote:
| Excellent. I actually like Apple's practice in this regard:
| they have a barebones/baseline functionality but allow third
| parties to provide a value added replacement that can be a
| first class replacement.*
|
| Apple is _almost_ there with mail, addressbook, and calendar
| but perhaps surprisingly they aren 't as seamless as it is
| with passwords.
|
| * For example this allowed me to plug 1password into my
| parents' phones and computers and use the shared vaults to
| make sure I could help them get unstuck from various web
| sites. Plus when they pass on I'll still be able to help the
| surviving parent to get access to things they need from the
| other parent's device. The apple one is disabled so they
| can't even accidentally get something confusingly stored in
| it.
| camkego wrote:
| For those in the know, will I be able to export my private keys
| and data from Passkey somehow, so that if I wanted to, I could
| switch to another FIDO device or system?
|
| I would speculate Apple is not going to support this, and Apple
| will retain control of the private keys, and do the request
| signing like an old-school USB FIDO device, but I don't know for
| sure.
| stetrain wrote:
| They allow export of everything else in iCloud keychain so I
| don't expect this will be different.
| albertgoeswoof wrote:
| Does anyone know if this is different to Webauthn? You can
| already login with touchid/faceid, with the private key stored in
| apples keychain. Lots of sites support it, I just added it as 2FA
| to Mailpace (https://blog.mailpace.com/blog/why-we-use-webauthn-
| for-2fa/), making it passwordless login instead of 2FA is trivial
| and fully supported by webauthn.
|
| What's different about this?
| jrockway wrote:
| Reading the linked page, it certainly looks very similar. I've
| also implemented WebAuthn from scratch and the term "relying
| party" is burned into my brain, and this document also uses
| that term. It's a reasonable term to use in any authentication
| context, though, so not a smoking gun I guess.
|
| WebAuthn continues to work great on iOS and Mac OS, so I'm not
| sure there's a good reason to add some other new standard.
| (Though I do have the controversial opinion of wanting Apple to
| share my credentials between all devices. I have my iPad,
| iPhone, Macbook, and portable security key all enrolled in SSO.
| I don't mind this but I feel like it probably hinders adoption
| over an easily-hackable pasword that you just remember.)
| tialaramex wrote:
| Relying Party is the jargon for the entity that gets to
| _rely_ on the fancy cryptographic technology to determine
| something that would otherwise be difficult / expensive /
| unreliable. They're relying on the maths working, and on
| certain other parties doing their jobs correctly.
|
| Everybody here is a Relying Party when they use HTTPS. The
| Web PKI promises that this is really news.ycombinator.com to
| you, the HN reader, so long as the math works (RSA, Elliptic
| Curve Cryptography and likely AES) and so long as your
| browser vendor did their job, and the Issuing CA (DigiCert)
| did their job.
|
| Relying Parties should ideally know why their trust is well-
| founded. For example, in the Web PKI examining this
| cryptography is the job of the Internet Research Task Force
| (related to the IETF), the browser vendors are responsible to
| you directly, and the Root CAs are overseen by m.d.s.policy,
| run by Mozilla on behalf of their users and everybody else's
| users.
| anony999 wrote:
| >> Apple has described Passkey as a new kind of credential in
| the iCloud keychain. The technology is based on the Web
| Authentication API (WebAuthn), a rapidly emerging standard that
| uses public key cryptography instead of passwords for
| authenticating users to websites and applications.
|
| Whatever "based on webauthn" means...Let's hope it's not just a
| buggy implementation of WebAuthn as they did with OpenID
| Connect
| [deleted]
| swamp40 wrote:
| Same as what they did with Bluetooth and AirTags, AirPods,
| etc.
|
| They start with the standardized technology, do their little
| twist (which usually involves fixing some standardized bug
| that affects performance and people have been complaining
| about for years), and patent it.
| aseipp wrote:
| Passkeys are available for general use in any application
| through the system frameworks, not just the browser; they
| simply use WebAuthn under the hood, but it's meant to expand
| support outside of the browser for more apps in more use cases.
|
| I wrote another comment elsewhere but there are some other
| issues with using WebAuthn as a primary authentication
| mechanism right now, especially things like new device
| enrollment when using platform authenticators (not trivial but
| not what people are used to), so most people opt to design it
| as a 2FA mechanism since that normally fits into existing
| designs easier ("just another auth device" like TOTP or SMS.)
| So Passkeys will help smooth that a bit for Apple users.
|
| Also we still need ways of exporting keys and software (like
| 1password) needs to synchronize them, manage them securely.
| There's still a long ways to go on that front, which probably
| won't be handled until stuff like this has settled.
|
| If you can use WebAuthn today in the browser and handle new
| device enrollment and have designed with it in mind as a
| primary auth mechanism, you're way, _way_ ahead of the curve.
| This is just Apple 's attempt to help kick the can further down
| the road for their users; you may not need to use Passkeys at
| all. There's just more to do before we can actually use
| WebAuthn as the basis to replace passwords in more places.
| judge2020 wrote:
| > Also we still need ways of exporting keys and software
| (like 1password) needs to synchronize them, manage them
| securely. There's still a long ways to go on that front,
| which probably won't be handled until stuff like this has
| settled.
|
| That's the point of passkeys here: iCloud Keychain syncs
| them, and if you want to use your keys on a non-apple device
| you'll be able to scan a QR code, which initiates a new BLE
| connection so that your phone can sign the login request
| remotely.
| kps wrote:
| I'm writing this on a non-Apple computer that doesn't have
| any radios. Now what?
| imwillofficial wrote:
| You don't use the feature.
| stetrain wrote:
| Then use another password manager that supports passkeys?
|
| Like 1Password
|
| https://blog.1password.com/1password-is-joining-the-fido-
| all...
| dkonofalski wrote:
| We scrap the whole thing since it didn't work for 1
| person...
| drexlspivey wrote:
| What exactly is your point? You can just add a yubikey or
| any other device that uses WebAuthn to the service you
| want to authenticate with.
| WorldMaker wrote:
| Buy a cheap USB dongle for BLE?
| booi wrote:
| Also, in what world can you buy a computer with no radios
| anymore. Even $10 SOC computers have radios.
| skykooler wrote:
| Many desktop motherboards don't have onboard wifi or
| bluetooth, so unless you installed a card for that they
| are limited to ethernet.
| aseipp wrote:
| Yes, obviously, but I was mostly referring to being able to
| share outside iCloud keychain, and in general 3rd party
| software support for this -- but, I wasn't aware of the BLE
| option, which is very interesting! I'm already very
| invested in 1Password (which I would like to integrate
| somehow, ideally) but that's good to know
| stetrain wrote:
| https://blog.1password.com/1password-is-joining-the-fido-
| all...
| tialaramex wrote:
| As far as I can see this is Apple's (thus macOS / iOS) platform
| for FIDO, whereas WebAuthn does FIDO for the Web.
|
| So, if you have macOS or iOS software for Mailpace, this is a
| way to have the same workflow for that as you get with WebAuthn
| for the web site.
|
| Android likewise has an API for apps to get this, as well as
| the Chrome browser on Android having WebAuthn, and if you have
| apps on both platforms it might make sense to do that there
| too.
|
| Technology wise the key difference is that for WebAuthn the
| Relying Party ID - the thing that distinguishes GitHub from
| Facebook (for example) is based on a DNS name, and that's
| verified by your web browser, while for these app APIs the RPID
| is based on some platform identifier and is verified by the
| host OS.
|
| So, GitHub won't get your Facebook credentials because
| github.com and facebook.com are different DNS names. Likewise
| "The 100% Legit Mailpace App" on iOS can't get the credentials
| for "Albert's Real Mailpace App" because they have some
| different internal iOS ID.
|
| At the backend, validation is pretty similar except the RPID is
| different, and you'll need to read the documentation carefully
| to figure out what the RPID is for these app APIs, if you have
| a pile of magic numbers for "your" app it's probably one of
| those. You don't get to specify, because the whole point is
| that nobody can impersonate your app (well, obviously on an
| iPhone Apple could impersonate it, and on Android Google could)
| dwaite wrote:
| > Technology wise the key difference is that for WebAuthn the
| Relying Party ID - the thing that distinguishes GitHub from
| Facebook (for example) is based on a DNS name, and that's
| verified by your web browser, while for these app APIs the
| RPID is based on some platform identifier and is verified by
| the host OS.
|
| The native APIs on Android, Apple and Microsoft platforms
| leverage relying party IDs which are web origins (e.g.
| https://github.com) whether doing native or web apps. The
| same native API is typically used by say Github Desktop as
| say the Chrome Browser.
|
| A native app needs an entitlement and a file on the web
| server to enable functionality for particular domains. A
| browser gets an entitlement to request credentials for all
| domains.
| [deleted]
| gigatexal wrote:
| Any word if something like this can be shared with Bitwarden?
| Rafert wrote:
| Why not, it seems to be coming to 1Password:
| https://www.youtube.com/watch?v=lYFxfchhR1g
| mhoad wrote:
| How do I leave the Apple ecosystem if I go all in on this? Sounds
| like major vendor lock in under a deceptive title of "open
| standards" but I'm hoping I'm wrong here. Does anybody happen to
| know yet?
| stjohnswarts wrote:
| I always was curious about this stuff. I don't want all my eggs
| in a basket and have to depend completely on others for
| "logging in". Apple and Google and other Big Corps(tm) have
| shown they are just fine with terminating your accounts without
| any recourse and/or warning with no practical way to appeal it.
| Passwords managers aren't subject to that limitation and all
| faang companies can do is kill your accounts for their
| particular services.
| gwbas1c wrote:
| As long as your account is tied to your email address, there
| should be something similar to a password reset.
| Ajedi32 wrote:
| Yeah, that's going to be the next big ecosystem challenge for
| WebAuthn in my opinion. Ideally platforms would support 3rd
| party password managers, so you could manage your keys without
| having to tie your credential database to any one specific
| platform.
|
| I'm sure as the popularity of WebAuthn grows there'll be more
| and more demand for cross-platform compatibility until
| eventually the big players are forced to implement it, but it's
| going to be kind of rough in the short term until then.
| ChadNauseam wrote:
| That would be nice. I used Hanko for one service I built that
| uses WebAuthn+email, so new devices get a one-time code in
| their email and existing just use WebAuthn. It would be kind
| of nice not to have to rely on email, but it's better than
| making people remember passwords.
| mhoad wrote:
| Except Apple are kind of notorious about avoiding cross
| platform compatibility which is why I ask. Find them hard to
| trust at this point.
|
| I can already hear them making the "we can't because it will
| impact users security" argument in my head.
| stetrain wrote:
| For normal passwords they currently seem to support third
| party password managers just fine, including direct
| integration in Safari and the iOS keyboard.
|
| You can also export everything from iCloud Keychain to use
| with another password manager.
|
| They could always use Passkeys as an opportunity to lock
| things down but it would be in direct contrast to what they
| have been doing with password management recently.
| floatboth wrote:
| Just add more authenticators to every RP (site you auth into).
| From the point of view of an RP, "your account in the Apple
| ecosystem" here is the _exact_ same thing as "one of your
| Yubikeys", basically.
| jml7c5 wrote:
| That seems like an enormous pain if you have dozens or
| hundreds of services. It could take hours to do this one at a
| time. (I'm assuming one minute per service, though that
| depends on how hard it is to find the "add another
| authenticator" page for each service.)
|
| It's possible I'm unaware that there is a simple protocol for
| this. Am I incorrect here?
| Spivak wrote:
| Yeah this is absolutely not feasible, I have ~200 separate
| accounts in my password manager right now just for me
| personally.
| danieldk wrote:
| I also have hundreds of accounts. But there are ~10
| services that are far more important to me and where I
| care a lot about security beyond passwords (Fastmail,
| Dropbox, GitHub, Google Apps, Bank, government websites,
| etc.). I use most of them already with an U2F key and
| I'll use them with Passkey.
|
| The hundreds of other sites will probably take years to
| support Passkeys (they don't support U2F either). I can
| convert them when they support it and I happen to do
| something else account-wise.
|
| I don't think it's a huge issue.
| zamalek wrote:
| You are 100% correct that you need to add it to each
| service. This is a consequence of an intentional decision
| (keys cannot be duplicated). Streamlining it would
| definitely be an improvement.
|
| That being said, it's not a problem in the real-world
| because FIDO is so sparsely supported. Hopefully PassKey
| speeds things along.
| eurasiantiger wrote:
| Could it be automated by a third-party service?
|
| How much would you be willing to pay for such a service?
| ;)
| mensetmanusman wrote:
| Streamlining would be an improvement, but it opens an
| attack vector.
|
| Unfortunately, security and usability are always in
| balance.
| zamalek wrote:
| I should have been more specific. Test how many clicks it
| takes to add a key to one of your "mainstream" accounts.
| We would hope that services which support FIDO eventually
| gravitate to a single UX language, that also reduces the
| time taken to register new keys.
| zozbot234 wrote:
| The relevant WebAuthn standard actually supports keys
| regardless of whether they can be duplicated. Even
| "virtual", software-only keys are supported. It's up to
| each individual service whether they allow the user to
| enroll such keys.
| floatboth wrote:
| Well, realistically not all services will support
| WebAuthn... spending an hour to handle a dozen important
| ones doesn't sound like a big deal to me.
| drexlspivey wrote:
| You should always add at least two keys for every service
| in case you lose the first anyway. That was the case even
| before Apple passkey so just keep doing the same.
| skybrian wrote:
| For less important accounts, you could use OAuth with
| another site. (For example, maybe use GitHub to
| authenticate for other developer sites.)
| Hamuko wrote:
| It's probably more painful than that.
|
| Let's say that I have two laptops, a MacBook Air and a
| Lenovo ThinkPad. I create an account with an Apple Passkey
| on a website. I can now log into my account on the MacBook
| Air, but not on the Lenovo ThinkPad.
|
| How do I register my ThinkPad? I need to log into my
| existing account to add a new authenticator (Windows Hello
| in this case). Does the website offer an email link I can
| use to log into the account? Do I have a backup code that I
| need to use? Do I need to set a password and log in the
| normal way (thus removing the advertised phishing and
| database leak benefits)?
| [deleted]
| yieldcrv wrote:
| I think we need a browser level or OS level notification about
| _which_ passwordless service we used last time.
|
| Did we use Gmail, Twitter, Signin with Apple, Github, Linkedin,
| or do I actually have something stored in my password manager
| associated with an email and if so, did I store it in the
| browser's password manager, the OS's password manager, or my
| third party password manager?
| dstroot wrote:
| Such a great point. I forget all the time. Next auth service I
| write will remember this for you and prompt you based on the
| service you used last time. Take my upvote!
| pvg wrote:
| The browser and the OS credentials managers essentially
| obsolete the third party password manger so that part is sort
| of 'solved'. Integration between the browser and OS one (with
| sync) is quite a bit trickier but the real blocker is that
| Apple and Google aren't much interested in solving it. The
| terawatts of brain power that went into the anonymized COVID
| tracker phone thing which turned out to be largely pointless
| could be applied to this, it just doesn't feel very likely.
| dkonofalski wrote:
| Why do you use more than one password manager? I have disabled
| all password managers in every app that I use except for the
| one I store things in. I have multiple folders with their own
| passwords too but they're all stored via the same solution.
| yieldcrv wrote:
| Because Google Chrome on iOS pops up asking to remember a
| password
|
| Safari on iOS suggests a password even if I'm trying to paste
| on in from my password manager
|
| OSX can be the same way
|
| They all sync
|
| and I never bothered to disable them because I never thought
| about it, but sometimes I'm in a rush with a service I think
| I'll never use again and use the suggested solution in one of
| the browsers
| jerf wrote:
| Unfortunately, and I hate to "victim blame" (though you say
| you are not yet a victim), I think you have to take some
| responsibility and use a password manager with
| deliberation. IMHO the browsers all make this worse by
| giving you something that seems to work and your first
| notice that it doesn't anymore is when it stops, which is a
| _terrible_ way for a security feature to work, but
| obviously they have incentives to lock you in, and boy oh
| boy is this one of the biggest ways that a browser can lock
| you in.
|
| I think you should resist sooner rather than later and
| switch to something cross-browser and third-party.
|
| But it's up to you, of course.
| tyingq wrote:
| >Why do you use more than one password manager?
|
| Work vs home is one driver.
|
| And for some cases, "Login with Google" or similar is nice
| because it integrates Google pay, removes sign-up friction,
| etc. I'm aware it has downsides, but it remains useful in
| some niche areas.
| dkonofalski wrote:
| Most password managers allow you to separate work from
| home, though. You don't need to store them in different
| platforms to have them in different places.
| [deleted]
| colemcallister wrote:
| I wonder what this means for services like Plaid and other
| aggregators. Will apps / websites continue on with standard
| username/password option?
| vorpalhex wrote:
| I'm ok if Plaid loses their model.
| acka wrote:
| Sorry for the somewhat but not quite off topic post, but can we
| please prevent HN from becoming yet another Apple billboard?
| There are more than enough of those already. Thank you.
|
| Yes I've heard that there may be some Apple manifestation going
| on or something but to have every little Apple tidbit hoisted
| directly to the front page (at least 7 articles and counting) is
| a bit much imho.
|
| Downvote me if you must, but I think it is important to have my
| opinion heard, and I don't think I am the only one.
| majewsky wrote:
| That's just how Apple does their announcements: in big piles at
| few dates. The alternative would be to dribble them out slowly.
| As someone who is not particularly interested in Apple news
| either, I actually prefer this. Better get it out of the way in
| one fell swoop than have one announcement every other week that
| dominates the discussion all the time. Things being as they
| are, there are 3-4 Apple events per year, and so there are
| 48-49 weeks without big Apple news.
| simplify wrote:
| This post is related to a large number of developers and
| startups (read: HN users), many of which have at least an iOS
| app or support safari. I don't see what the problem is.
___________________________________________________________________
(page generated 2022-06-06 23:00 UTC)