thekeyper

6 ms·

1.
by thekeyper 2y ago
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 stea
2.
by thekeyper 2y ago
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"). Gen
3.
by thekeyper 2y ago
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
4.
by thekeyper 2y ago
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 clear
5.
Show HN: Device-Bound Session Tokens in JavaScript(session-lock.keyri.com)
23 points by thekeyper 2y ago|11 comments
6.
by thekeyper 4y ago
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 i
7.
Mobile-like element transitions for the web(github.com)
3 points by thekeyper 4y ago|0 comments
8.
by thekeyper 5y ago
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.
9.
by thekeyper 5y ago
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
10.
by thekeyper 5y ago
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, o
11.
by thekeyper 5y ago
Thanks, will do! That's a clever platform.
12.
by thekeyper 5y ago
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 "peop
13.
by thekeyper 5y ago
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
14.
by thekeyper 5y ago
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 manag
15.
by thekeyper 5y ago
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
16.
by thekeyper 5y ago
> The way I use passwords is way safer than Keyri I don't see how that is possible. (1) Keyri private keys cannot be stolen other than through smartphone malware, which is exceedingly rare, while password managers and older USB keys
17.
by thekeyper 5y ago
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
18.
by thekeyper 5y ago
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 backu
19.
by thekeyper 5y ago
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.
20.
by thekeyper 5y ago
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", w
21.
by thekeyper 5y ago
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-
22.
by thekeyper 5y ago
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 pseudonym
23.
by thekeyper 5y ago
Login on desktop happens through scanning a QR code on the service's login page using the service's app. On a mobile device, logging in happens by tapping a button and being verified by biometrics (FaceID etc.) or a passcode (if e
24.
by thekeyper 5y ago
Two options, each configurable by the developer implementing the SDK: (1) When a user sets up their new phone using an iCloud / Google Drive backup of their old phone, the private keys will be already embedded in the relevant apps when
25.
by thekeyper 5y ago
Sent you an email. Anyone else - please let me know if you're having trouble with the demo here or email me - zain@keyri.co
26.
by thekeyper 5y ago
> Isn't this a problem then with WhatsApp Web login too Yes, it's an issue with WhatsApp QR login and every other QR login implementation. > I was also wondering if its a severe vulnerability It can be severe if the attacker
27.
by thekeyper 5y ago
That's a similar concept, though despite their claims of unphishability, it is phishable, since the QR code is portable, and that is the only item that the authenticating device reads. The contents of the QR code simply don't matt
28.
by thekeyper 5y ago
Regarding your first point: phones are already intrinsic to authentication, whether it's through SMS OTP, TOTP, or push notification verification. Wherever you have 2FA enabled (other than email magic link), you are generally SOL if yo
29.
by thekeyper 5y ago
Yes, even if bad actors figured out the secret sauce, they couldn't defeat it easily. It's possible, but if they hack you the way they'd have to hack you in order to defeat our CV element, you'd have much bigger problems
30.
by thekeyper 5y ago
Yes, there's more to it than just reading the QR code. As mentioned above, I don't think it's a very defensible tech differentiator right now (lots of better-funded cybersecurity companies out there), but in summary, the phon

More ›