search

sakurity / securelogin

This version won't be maintained!
MIT License
1.22k stars 35 forks source link

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

Closed deltaidea closed 7 years ago

deltaidea commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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!