121–130 of 274 posts
So roughly speaking this is WebAuthn for a web site, with the iphone acting as the dongle. It's a really good idea. I can see there being a big demand for just simplifying signin - I can easily see a time where it is worth not having the hassle of managing multiple signin processes and just choosing webauth or nothing. Edit: to be clear this won't affect B2C sites whose monetisation is based on getting as many people…
Earlier quoted context omitted.
Similar to how you would sign in on devices/browsers without WebAuthn support or don't have physical token (Yubikey/etc.) with you: use a fallback method provided by a website. This is usually TOTP or a scratch code. The website need to implement it though. One thing to keep in mind is this is not supposed to be the only factor required to sign in. It should be used as a 2nd factor in the similar way to TOTP (but wit…
With Okta (since gp mentioned it), you would sign in with a password, then click the "yes its me" button on your phone, or you could use TOTP, or even a yubikey.
What exactly does attestation do vs not having it? Can someone here explain clearly?
- the password is low-entropy/complexity, so it is guessable or brute-forcible. - the password is typed into the system, so keyloggers might observe it - the password might be stored insecurity by the server - the password is transmitted over the network and might be intercepted - the password is transmitted over the network, possibly to unintended recipients (like a phishing site) and thus is intercepted.
One alternative is employing public-key/private-key crypto. The server sends some random data to the user. The user signs that data with their private key (this is the attestation part). Only the signed data, which is generated for this single authentication attempt is transmitted. And during registration only the public key is transmitted. The public key is used by the service to verify the attested data. The private key remains secret the entire time. Likely it remains secret even to the user's machine because it lives in separate hardware, such as a yubikey or secure-enclave. The key is also something that isn't going to be guessed because we are using modern algos with large bit-sizes.
Earlier quoted context omitted.
This isn't really true any more. Apple requires their competitors' browser apps to use a 'webview' to display websites, and Safari does not use this. The iOS webview may share a layout/paint engine with Safari, but it is heavily restricted in other ways. Apps with webviews (like Chrome for iOS) can't have extensions, for example. But the subtlest, cleverest restriction is that webviews are forced to use an older and…
> But the subtlest, cleverest restriction is that webviews are forced to use an older and slower JavaScript engine. AFAIK that hasn't been true for years. WKWebView (as opposed to the old UIWebView) lets you use the full speed JS engine.
This really is just bringing WebAuthn to Safari. I've been using it via chrome w/ TouchID for our corporate okta SSO and it has been working great. WebAuthn is really just a way to make public-key/private-key crypto scale. The user never really knows about or interacts with the keys. The website doesn't store a password, they store a public key. The user doesn't know about the private key (paired to the public key) t…
How does this work if you need to sign in to a site on a borrowed computer while traveling or something? Is the private key derivable from a master password or something?
Earlier quoted context omitted.
It also doesn't add any security. Your password can still be guessed or phished. When authenticating with a cryptographic token (U2F/WebAuthn), that vector goes away. (Even OTP can be phished... the phishing site can just ask you for the code.) Password managers do make it more difficult to get phished, since they will not know what password to autofill on phishing.example.com... but on the other hand, password manag…
WebAuthn is less phishing resistant than it should be. The original intent was that WebAuthn + token binding would ensure that, even if an attacker obtained a fraudulent certificate for a victim site and had an MITM position on the network, the attacker still couldn’t steal a WebAuthn protected session. Alas, Chrome removes its token binding implementation, and WebAuthn no longer has this property. If you authenticat…
So you are vulnerable to an active MITM, but they don't actually acquire any private secrets to be used to create their own sessions. MITM with passwords OTOH, gives the attacker your password.
Earlier quoted context omitted.
There are some differences between Safari and WKWebView. Some features are blocked.
It's funny how much bashing Google gets for monopoly with Android, pushing users to use Chrome, Play Store and whatnot. While all of that is relevant, Apple's stranglehold seems much more and worse.
Earlier quoted context omitted.
Do you know how it works?
That's the point , not many do
What exactly does attestation do vs not having it? Can someone here explain clearly?
With passwords, the "proof" or "attestation" is that nobody knows my secret password. In practice this tends to be weak. Some reasons this is so includes: - the password is low-entropy/complexity, so it is guessable or brute-forcible. - the password is typed into the system, so keyloggers might observe it - the password might be stored insecurity by the server - the password is transmitted over the network and might…