Save private keys in non-volatile areas about unilogin HOT 14 CLOSED

I will take on this task.

I have implemented this in the boomerang fork of this project for just local storage, but I would like to research this topic more and develop a more secure solution

from unilogin.

Interesting, didn't knew such options existed, sounds good. To reiterate: I'm against having the user download their local private key. That's what the backup codes are for.

from unilogin.

How about something like the OAuth2 implicit grant flow:

1. User reaches DAPP website
2. User clicks log in
3. User is redirected to IPFS URL for universal login page, with list of requested scopes, e.g. send transaction to contract X with value up to Y and arguments Z0, Z1, ..., send ETH up to X wei
4. If user is already logged in (localStorage) ask if requested scopes may be granted to the DAPP, otherwise log in using the demo flow
5. Wait for transaction to authorize access key to be confirmed
6. Redirect back to DAPP URL with private key in the URL fragment (which is not sent to server) and only works for a temporary duration

This allows the login page to be consistent (good for security) and limits damage that a malicious or hacked DAPP developer can cause with a private key

It also allows the DAPP developer can use universal login without incorporating any universal login SDK code

from unilogin.

After doing some research, LocalForge seems like the best option.

My plan:

1. Yarn Install LocalForage
2. Create StorageService.js
3. Create 3 instances of LocalForge with 3 different driver types (IndexedDB, Websql, and localstorage)
4. On first login on a device, store private key in every instance of localforge (DB, WebSQL, and localstorage)
5. On retrieve function in StorageService, query DB, if fail, query WebSQL, if fail, query LocalStorage driver.

from unilogin.

I’m working on this issue on this branch
https://github.com/Kyrrui/UniversalLoginSDK/tree/persistent-storage?files=1

from unilogin.

Local storage isn’t secure. For example, if one application using the SDK has a cross site scripting vulnerability, it can read local storage of the host and steal funds. Or, if the DNS is hacked, that can also expose local storage to attackers.

With my understanding of how universal login works, exposing the private key of a single app can expose a user’s funds in the proxy contract.

Instead, I would recommend moving universal login to a browser extension, and injecting an ethereum provider. This is an extra step that was deliberately avoided, but it’s the only way to persist a user’s authentication on a single website without exposing it to the site JavaScript and has the benefit that you authenticate the browser client instead of each individual app.

Heard about this issue in other apps in devcon4 talk by @tayvano

from unilogin.

@moodysalem Are localDB and webSQL vulnerable as well? The library I use tries those two storage methods before it ever touches localstorage.

from unilogin.

Yes, and actually the problem isn’t just attackers targeting the website but also the developer of the website. E.g. if I’m malicious I might create a nice looking wallet and get users to log in to see their funds which gives me access to a private key to their proxy contract-even though my app may function perfectly well I now have access to a private key to do what I please.

I think that the storage and handling of the private key can’t happen in the same security context of the DAPP JavaScript. It puts too much trust in the DAPP developer to not be malicious nor hacked by a malicious user

What’s needed for this to work is probably a new web API for storing and using asymmetric key pairs without exposing the private key, but I still wouldn’t trust a malicious website to use that enclave and hide my keys.. I think a browser extension is the right solution

from unilogin.

Ahh, okay I see what you mean and have had similar concerns. I think the solution for now is to have open source dapp code which a user can deploy themselves — that way if they are really concerned about security they can interact with the relayer and contracts on their own instance of the dapp and can trust the code since they can audit themselves wether a key is being sent

from unilogin.

If private keys on the device are limited in scope and duration this is fine, they are a lot like OAuth2 access tokens. But there has to be a few root devices or apps that have full permission, including to authorize new devices. The onboarding experience would have to happen in a trusted app or an account could be compromised immediately and the user wouldn’t know until they get owned.

from unilogin.

from unilogin.

Hey @moodysalem, I'm working on a solution to this that we can hopefully integrate into this project - check out http://tor.us

from unilogin.

@Kyrrui can you describe the solution implemented at tor.us?

from unilogin.

@moodysalem Sorry it took so long to get back to you. I'm new at Torus and have only dabbled into the full solution, but we're using a modified version of Shamir's Secret Sharing called Publicly Verifiable Secret Sharing. We will have a handfull of nodes that are controlled by orgs such as Consensys, Binance, and a few other big names. By querying these nodes you can assemble your private key, but none of these nodes individually can determine your private key.

from unilogin.