Actually, Session-Lock does offer some protection against some MITM attacks in the form of a timeout that would be triggered with most MITM attacks, but its purpose (and that of Chrome's DBSC proposal) is to protect against cookie stealer malware, not MITM. This is malware that steals session tokens from the device's filesystem. Take a look here to understand the threat: https://blog.google/threat-analysis-group/phishing-campaign-...
The premise of Session-Lock and DBSC is that even if the token gets stolen, it would not be useful to the attacker because the server would reject it if it doesn't have the correct signature that's generated using a private key that should only exist on the legitimate device. This private key has to be difficult or borderline impossible for the attacker to exfiltrate, unlike the session token.
httponly cookies are meant to prevent attacks like XSS by preventing access to them from client-side JS. However, they can still be stolen by malware on the device (there's a whole class of them called "cookie stealers"). Generally, they search through the infected machine's filesystem and pull out any cookies they find, or at least cookies that the attacker would be interested in. No client-side JS is required for this, so the httponly attribute doesn't help. There have also some browser extension-based cookie stealers that may work along similar principles. Take a look at this old open source stealer to get a sense of how they work: https://github.com/Alexuiop1337/SoranoStealer/tree/master/So...
Session-Lock and Chrome's DBSC are designed to combat these cookie stealers specifically. The premise is that even if an attacker exfiltrates the token itself, it would not be able to be used because the server would reject it if it is not signed by the correct private key when the network request is made. This private key can (or should) only exist on the legitimate device, not the attacker's machine. There may or may not be ways to extract the private key as well, but in any event, it would be a much more complicated attack.
Glad to hear it. I feel the library could be improved, and if your server runs on something other than Node.js, you'll have to put together some straightforward crypto code, so feel free to file an issue on the repo[1] if you have any questions or requests. The point of it is not at all to compete with Google, but it could serve as a reasonable stopgap that's easy to implement (no new endpoints, no roundtrips) and should protect against all of today's cookie stealers, which would have to become a lot more sophisticated to beat it. I created a discussion on DBSC's spec repo yesterday that has a more direct comparison vs. Google's proposal[2] that you can check out.
If the browser loses the private key from IndexedDB, the session token will become invalid because it would no longer be able to be verified on the server. Basically, the user would get logged out in the same way as they would if they cleared out the session token by clearing cookies or LocalStorage.
Hi! Very cool project. Just out of curiosity, what trips up Crawlee on CreepJS? I haven't heard of anyone actually using it in production (actually don't think it's meant for production use). It's certainly overzealous in its aggregate "trust score", but (a) it seems like a good benchmark to aim for; (b) some of its sub-scores, like "stealth" and "like headless", might be helpful for Crawlee to evaluate, given the signals included in those analyses are fairly simple for people to throw together in their own custom (production) bot detection scripts and are somewhat ubiquitous.
SIM swapping is relatively common in the US because it's not difficult to execute via social engineering. I'm not sure what the situation / protections against SIM swapping are in Scandinavia. https://en.wikipedia.org/wiki/SIM_swap_scam
I think usage-based pricing is more fair than per-seat pricing, and it makes much more sense for SurveyMonkey than per-seat pricing. Usage-based pricing also eliminates account sharing concerns because a given customer can provision as many accounts to their employees or friends/family as needed.
Our system does not support people without smartphones, which is why we are addressing companies that are mobile-first or generally have more tech-forward userbases with ~100% smartphone adoption. For mobile-first platforms in particular, our system helps them flesh out a "WhatsApp-like" auth UX, which is industry leading in our opinion, without a long development cycle.
Agreed that WebAuthn is valuable in mobile-only cases, but I don't think it can transition to desktop web for a large majority of people. The overlap in a Venn diagram of "people who use hardware security keys" and "people without smartphones" just seems vanishingly small. BTW, Keyri also uses the TPM / secure enclave as its key store.
The contention on account sharing is "robbing companies of revenue". It is not related to additional costs imposed on companies due to account sharing. A non-negligible number of people engaged in account sharing are enjoying real value from the service(s) they are not paying for and would pay for if they could not account share. Hence account sharing enables the loss of potential revenue. As stated in another reply, if a company sees value in allowing customers to share accounts, they can build provisioning mechanisms that align with their TOS as Netflix has done.
Thanks, this question touches on a very significant point.
Backup and recovery currently are handled by iCloud and Google Drive through Keychain and KeyStore, respectively, both of which form the backbones of Apple and Google password managers, respectively. The two cloud backup services (a) are fully encrypted both in transit and at rest and (b) are managed by Apple and Google, not Keyri. So the only parties that "see" the private keys are the user and Apple or Google, and the latter two only see encrypted copies of the keys, same as they only see encrypted copies of their users' saved passwords. Recovery also happens through Apple or Google when a user sets up their new phone using iCloud / Google Drive backups of their old phones, which are also encrypted in transit and at rest. Developers can additionally require users to enter a pre-specified passcode in order to decrypt their private key upon recovery, which involves another layer of local encryption.
Key pairs are generated locally on the device (i.e., Keyri's API does not generate/provision them). Private keys are stored encrypted at rest in phones' secure enclaves and only decrypted at run time once biometric verification is passed.
Fair point. As you implied, security key adoption, particularly for the consumer-facing web, is very low, as is support for more secure security keys (FIDO2) by consumer-facing web services. We're trying to bring that level of security to mass audiences through a simple UX that a minority audience (that dislikes relying on phones for authentication) may dislike. That said, we think our phone-based auth security and UX are better than those of SMS OTP, TOTP, and push notification verification, so hopefully we can convince that audience over time.
(1) Keyri private keys cannot be stolen other than through smartphone malware, which is exceedingly rare, while password managers and older USB keys are vulnerable to desktop malware, which is much more common - both credential stealers and, in the case of older generations of Yubikeys, keyloggers. Hardware OTP devices are additionally vulnerable man-in-the-middle phishing attacks (though the HN audience is generally savvy enough to not fall for phishing) - https://github.com/kgretzky/evilginx2.
(2) As long as you rely on passwords and TOTP, you're relying on the shared secret paradigm and trusting the relying party to handle your credentials properly. If the relying party's credential store is breached and the credentials were improperly stored (common even today), your credentials (both your password and OTP secrets) can be used by a bad actor to access your account. Public key systems like Keyri and FIDO2 substantially reduce this risk.
> As I said in a comment below, the fact that companies "can afford" is not the same as "it's worth it" to them
Please see my response below regarding account sharing. In short, eliminating account sharing in order to enforce TOS is an opportunity to (a) improve security (b) improve UX in cases where provisioning multiple users access to one account is warranted.
> Finally, with OpenID, I can set up my own identity provider, or use a privacy conscious one.
As you note, the vast majority of web services don't support arbitrary identity providers or use privacy conscious ones. History has proven that people don't set up their own identity provider. Additionally, the universe of "privacy conscious" OIDC providers is limited (non-existent?).
Eliminating account sharing does not preclude offering the ability to share seats. Zendesk could very well offer their customers a way to provision users like you a limited account or some other mechanism that allows commenting on a support ticket every now and then. For example, Netflix offers a mechanism to formally invite members of your household to your account for free, which is the scope of "account sharing" that they allow in their TOS.
Either way, it's in Zendesk's and Netflix's best interest to make sure that a given account is used only by the person they were told would use it when the account was purchased, both from a business perspective and a security perspective. How they can address the needs of their customers while enforcing their stated TOS with a mechanism like Keyri is up to them.
Correct, that's currently the case. Users can use QR code backup/restore functionality if enabled by the developer to switch between iOS and Android. That would have to be done app-by-app. We're working on our own cloud backup system to automate this.
I think such transitions between smartphone OSs already entail significant credential transfer issues, since saved passwords also do not automatically move between OSs.
You'd have similar problems if you used "Sign in with Apple" for an app on an iOS device and then switched to Android.
Yes, when developers enable passcode protection, the guess rate limiting is based on the OS default because it's accessing the same subsystem responsible for unlocking the phone itself.
Understood, thanks. I think the concept is excellent - truly a digital ID card that you can present with a simple cryptographic token, thus a real "proof of identity". Keyri is "proof of ownership of a trusted device", which, while being a narrower concept, we believe is more palatable from a go-to-market perspective, since companies prefer to proof identities in their own proprietary way.
The similarities with VPA/Alero end at the concept of QR-based login. It is a system for provisioning enterprise vendors and requires a substantial onboarding process. It is not an SDK for integration into consumer-facing / third-party applications.
Can't speak for how it works on the back end (though it clearly works differently from Keyri given VPA's QR code contains much more data and is therefore slower / more unreliable to scan). In terms of security on the front end, VPA is phishable as explained in earlier comment threads.
We do not use Hyperledger Aries, but thanks for showing us. I have a blockchain background, and Keyri is somewhat inspired by blockchain concepts, but we've stayed away from blockchain-based solutions for privacy reasons. The pseudonymity of traceable blockchain transactions (in the auth scenario, authentication request transmissions) do not provide adequate privacy. Apologies if I'm misinterpreting Aries - perhaps its ledger is not publicly viewable. I have other objections to blockchain-based identity solutions, but privacy is the main one.
Then there are other passwordless auth solutions employing "private blockchains". That term basically means "database" in my mind and is obviously not ideal from a privacy perspective.
The premise of Session-Lock and DBSC is that even if the token gets stolen, it would not be useful to the attacker because the server would reject it if it doesn't have the correct signature that's generated using a private key that should only exist on the legitimate device. This private key has to be difficult or borderline impossible for the attacker to exfiltrate, unlike the session token.