Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An option to not store private key in plain text on user device #16

Closed
deltaidea opened this issue Jun 6, 2017 · 2 comments
Closed

Comments

@deltaidea
Copy link

deltaidea commented Jun 6, 2017

Currently a private key is derived from the master password and then stored on the device in base64. From this point on, the master password is never needed. The saved profile is all that's needed to authenticate. At least on Windows, that can be a concern. Malware could read AppData and steal the key.

Could you provide an option to encrypt the private key and require the master password?
Or even not store the key at all. Realistic use case: one-off authentication on a friend's device.

Edit: as it stands, this is essentially like a global cookie: it's saved on the device, and if you steal it, you don't have the user's password but can still act on his behalf.

@homakov
Copy link
Member

homakov commented Jun 6, 2017

The way it's stored now isn't great. It's priority to move localStorage.profiles to secure enclaves and similar keychains that arent' so easily accessed.

But there is no plan for app-wide passcode yet - here's the reason https://medium.com/@homakov/against-passcodes-in-apps-a76b9a00b242

Users are encouraged to use full disk encryption and a passcode on their devices. Apps are not responsible for this.

A basic password would be too easy to bruteforce, and we end up with waiting 20 seconds everytime for proper encryption? Not convenient. What's your solution?

One-off auth on a friend's device: the user should manually log out after using, that would destroy the key. But usage on public computers is really not a priority for this schemes, because no way to cover this corner case nicely.

Speaking of malware - it is impossible to stop even for hardware tokens, only Doublesign for 2.0 can protect from some kinds of requests, but no way to prevent malware riding login requests.

@deltaidea
Copy link
Author

move localStorage.profiles to secure enclaves and similar keychains that arent' so easily accessed

Ah, that makes sense.

a passcode on their devices. Apps are not responsible for this.

This is also completely reasonable.

Thank you! This addresses all my concerns. Good job with the protocol in that case!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants