How does GateHub store passwords and secret keys?

[enej]

1 hour ago, T8493 said:

But (currently) you don't store them permanently (in unhashed form). That's a difference.

Should we decide to start storing them (recovery keys) our TOS would reflect that and our users would be notified in advance.

We are actually thinking of offering a "backup" service for a simple reason that most people will loose their recovery keys and passwords. While that might work in "crypto world", everyday users want to be reassured we have a way of restoring their funds no matter what.

It's quite a challenge to achieve both convenience and security though.

 

1 hour ago, T8493 said:

So you have (at least temporary) access to plaintext passwords and you still can't decrypt secret keys? So how does the browser decrypt secret keys?

Browser can decrypt secret keys when you enter the password for the second time (on send payment modal for example). Until you do, neither our server nor your browser can decrypt secret keys.

 

If you want to be absolutely secure, you have to use cold storage. There is simply no better way.

P.s.: Having said that, I use GateHub Wallet with my personal ripple accounts everyday and can sleep at night just fine...

 

Edited August 4, 2016 by enej
typo

[Morty]

2 hours ago, gatehub said:

 

Q: What happens to an (encrypted) account secret if I delete Ripple account from my wallet? Is it still stored? Is it deleted from backups, too?
A: When you delete your ripple wallet, encrypted secrets stay in our databases and backups for a certain period of time until being completely removed. This is useful in cases where users accidentally delete the wallet so we can still recover it before it's purged from our databases.

 

How long is the certain period of time? Days, weeks, months?

[T8493]

4 hours ago, enej said:

Browser can decrypt secret keys when you enter the password for the second time (on send payment modal for example). Until you do, neither our server nor your browser can decrypt secret keys.

Can you please explain this because your answer confuses me a little bit.

Why would your server decrypt keys? Isn't all signing done in browser?

What technically/cryptographically prevents your server from decrypting secret keys when it receives password for the first time (during the processing of HTTP POST request to https://api.gatehub.net/auth/oauth/token )?

 

 

Quote

If you want to be absolutely secure, you have to use cold storage. There is simply no better way.

Well, the point of using Ripple is also trading and providing liquidity and not just holding XRPs in a cold storage hoping for a better price. That's why I'm interested in GateHub Wallet.

 

Edited August 5, 2016 by T8493

[culminator]

11 hours ago, gatehub said:

however a malicious player would also have the power to implement a backdoor in the client side

This could be mitigated to some extent with a status page with script verification similar to what blockchain.info status page has. Sure, it depends on users checking the page before using the wallet. Not everybody will do that but those who do check and spot that code was tempered with will alert others and in that way the hack would be spotted (edit: if github repo or status page themselves was not hacked) much faster.

Could someone explain "for dummies" which part and why cannot be encrypted/decrypted client-side and thus plain password through https needs to be sent? Ripple Trade (and previous Ripple Client) did not send plain passwords (though have not checked this myself), just hashes to get blob  which was decrypted client-side. What is preventing similar implementation?

Edited August 5, 2016 by culminator

[karlos]

moved to gateways

[Hodor]

@enej and @T8493, this is a fantastic dialogue on the topic - this sort of active thinking is what makes for stronger security.  Thanks.

[T8493]

5 hours ago, culminator said:

This could be mitigated to some extent with a status page with script verification similar to what blockchain.info status page has. Sure, it depends on users checking the page before using the wallet. Not everybody will do that but those who do check and spot that code was tempered with will alert others and in that way the hack would be spotted (edit: if github repo or status page themselves was not hacked) much faster.

Another solution is to package javascript in the form of a browser extension: https://blockchain.info/wallet/browser-extension

[enej]

15 hours ago, Morty said:

How long is the certain period of time? Days, weeks, months?

Couple of weeks.

13 hours ago, T8493 said:

Why would your server decrypt keys? Isn't all signing done in browser?

What technically/cryptographically prevents your server from decrypting secret keys when it receives password for the first time (during the processing of HTTP POST request to https://api.gatehub.net/auth/oauth/token )?

I merely wanted to point out that the only time secret keys can be decrypted is when you've already logged into your wallet and you've enter the password for the second time. This can only happen inside your browser. Additionally our service architecture prevents authentication service to access (encrypted) secret keys.

6 hours ago, culminator said:

This could be mitigated to some extent with a status page with script verification similar to what blockchain.info status page has. 

We have similar measures in place for our services as part of our deployment process.

6 hours ago, culminator said:

Could someone explain "for dummies" which part and why cannot be encrypted/decrypted client-side and thus plain password through https needs to be sent? Ripple Trade (and previous Ripple Client) did not send plain passwords (though have not checked this myself), just hashes to get blob  which was decrypted client-side. What is preventing similar implementation?

Passwords are securely transmitted (via SSL) to our authentication service where we hash them and store hashes to our database. While we could technically do this client side it wouldn't necessarily be more secure. Since our code is not open source we might as well "collect" passwords on our signin page, encrypt them with some key and send them somewhere ... to be clear WE DON'T.

As Luka wrote earlier:

" To be frank, if GateHub was malicious we would be able to sniff passwords on the server side at signin.gatehub.net, however a malicious player would also have the power to implement a backdoor in the client side. It really boils down to trust here. We do not know your passwords because we do not want to know them. "

49 minutes ago, T8493 said:

Another solution is to package javascript in the form of a browser extension: https://blockchain.info/wallet/browser-extension

We are thinking of creating open source "paper wallet" with basic functionality for signing transactions. Muck like the "minimalist ripple client": https://jatchili.github.io/minimalist-ripple-client/ that wallet would be easily downloadable in a form of one page html and could be used to sign transaction in a safe environment (offline PC or VM).

Our ripple tools that we use for signing transactions of our gateways will also be available on Github. Stay tuned.

[culminator]

27 minutes ago, enej said:

Passwords are securely transmitted (via SSL) to our authentication service where we hash them and store hashes to our database. While we could technically do this client side it wouldn't necessarily be more secure. Since our code is not open source we might as well "collect" passwords on our signin page, encrypt them with some key and send them somewhere ... to be clear WE DON'T.

As Luka wrote earlier:

" To be frank, if GateHub was malicious we would be able to sniff passwords on the server side at signin.gatehub.net, however a malicious player would also have the power to implement a backdoor in the client side. It really boils down to trust here. We do not know your passwords because we do not want to know them. "

I do not think anyone here is doubting benevolence of GateHub, although rouge employee is always a possibility. The point I am trying to make is that if password is sent to authentication server it can possibly be sniffed and collected without anyone noticing as opposed to situation where it would be necessary for attacker to change javascript  code which can be compared to legit version on external status page and attack possibly being intercepted earlier.

[T8493]

19 hours ago, culminator said:

I do not think anyone here is doubting benevolence of GateHub, although rouge employee is always a possibility. The point I am trying to make is that if password is sent to authentication server it can possibly be sniffed and collected without anyone noticing as opposed to situation where it would be necessary for attacker to change javascript  code which can be compared to legit version on external status page and attack possibly being intercepted earlier.

I also share this view.

GateHub service should be "provably secure", but right now it isn't. You (or an attacker) have the ability to access secret keys without anyone from the outside noticing it.

I'm not saying that you're decrypting secret keys, I'm saying that you have the ability to do it (despite your TOS claiming otherwise).

20 hours ago, enej said:

Additionally our service architecture prevents authentication service to access (encrypted) secret keys.

There's another thing I forgot to write about before. When you change your password, there is one HTTP request which contains: new password in plaintext and (newly) encrypted master key. I'll need to check the endpoint of this API call, but maybe it is the same endpoint that is used for authentication.

So it looks like you have services ("Password change service") which have access to all data that is needed to decrypt the master key.

If attacker gains access to this "password change service", he can decrypt all secret keys later even after the users change their passwords (change of password doesn't help at all).

There could be one another issue, but I'll create separate thread for it. Another possible (and possibly related) issue.

 

 

 

Edited August 6, 2016 by T8493

[jhamel56]

Interesting reading this post from 3 years ago

[JohnS0N]

Indeed. They haven't done anything to secure their website even after they were warned about these exploits. And probably nothing was done after the latest attack a few months ago either. This should serve as a reminder that anyone who still has the tokens with them, should move them to a ledger quickly.

[minotauruk]

i'm amazed that people are still trading on this platform.