Jump to content

Gatehub and Plain Password


winthan

Recommended Posts

In earlier post, Gatehub claims that they don't keep password in simple format, and they said that Gatehub keeps our password in encrypted.

If gatehub keeps our password in encrypted. why should our password in clear format sends to their API at login page, rather than encrypted password?  Is that okay to send plain password to server? Should It be encrypted string than our simple password if they don't keep our password, right? 

AFAIK if someone could hack API for token page, then we are screw liked recent hacking of bitcoins. 


 

gatehub.png

Edited by winthan
Link to comment
Share on other sites

5 hours ago, winthan said:

In earlier post, Gatehub claims that they don't keep password in simple format, and they said that Gatehub keeps our password in encrypted.

If gatehub keeps our password in encrypted. why should our password in clear format sends to their API at login page, rather than encrypted password?  Is that okay to send plain password to server? Should It be encrypted string than our simple password if they don't keep our password, right? 

AFAIK if someone could hack API for token page, then we are screw liked recent hacking of bitcoins. 

 

A little bit simplified explanation:

When you enter password in the browser and you press "Sign in" button, browser establishes encrypted TLS connection from your computer to the server api.gatehub.net. The content of the HTTP request (which includes password in plaintext) is therefore encrypted and then decrypted on the server.

Technical detail: this server doesn't belong to GateHub. It belongs to CloudFlare. CloudFlare then establishes separate TLS connection to the "real" GateHub server, encrypts the request again and sends it to the "real" GateHub server.

Password IS encrypted during the transfer from your browser to the cloudflare server.

However, GateHub doesn't store passwords in the encrypted form. GateHub hashes passwords (+some salt) and stores these hashes. There's one big difference between these two approaches. If you encrypt password, then you can also decrypt it (if you have the key). But if you calculate hash of the password (+some salt), then you can't "decrypt" it - you can't efficiently calculate password which produces this hash (hash functions are one way functions).

GateHub backend server MUST see password* which produces the hash stored in the database.  If one uses JavaScript to calculate hashes of the passwords in the browser and the browser then sends these hashes to the server, then the following attack is possible: attacker steals the database which contains hashes of passwords and then uses these hashes from the stolen database to log in to GateHub servers as another user. EDIT: attacker can't calculate passwords from the hashes; if server wants to see plaintext/unhashed passwords instead of the hashes, then the stolen hashes are useless.

* there are some other approaches, too (for example, digest access authentication)

The main issue with the GateHub approach is that GateHub sees your unencrypted/unhashed password and this password can decrypt master key which can be then used to decrypt secret keys.

There are several solutions to this. One is to have two passwords: one for authentication and another one for decryption of secret keys.

Similar approach is to derive two "passwords" (using key derivation functions) from one plaintext password. One could be sent to server for authentication and another could be used for decrypting master key and secret keys.

 

 

 

 

 

 

Edited by T8493
Link to comment
Share on other sites

5 hours ago, T8493 said:

It belongs to CloudFlare.

@T8493 Thanks for explanation, btw can we trust CloudFlare? And I think, Gatehub is having flexible SSL.  BTW, which SSL option is being used at gatehub.  I see only cloudfare certificates only. 

 

Link to comment
Share on other sites

2 hours ago, T8493 said:

 

A little bit simplified explanation:

When you enter password in the browser and you press "Sign in" button, browser establishes encrypted TLS connection from your computer to the server api.gatehub.net. The content of the HTTP request (which includes password in plaintext) is therefore encrypted and then decrypted on the server.

Technical detail: this server doesn't belong to GateHub. It belongs to CloudFlare. CloudFlare then establishes separate TLS connection to the actual GateHub server, encrypts the requests again and sends it to the actual GateHub server.

Password IS encrypted during the transfer from your browser to the cloudflare server.

GateHub doesn't store passwords in encrypted form. GateHub hashes passwords (+adds some salt) and stores these hashes. There's one big difference between these two approaches. If you encrypt password, then you can also decrypt it (if you have the key). But if you calculate hash of the password (+some salt), then you can't "decrypt" it - you can't efficiently calculate password which produces this hash (hash functions are one way functions).

GateHub backend server MUST see password* which produces the hash stored in the database.  If one uses JavaScript to calculate hashes of the passwords in the browser and the browser then sends these hashes to the server, then the attacker can steal the database which contains hashes of passwords and then use these hashes from the stolen database to log in to GateHub servers as another user. EDIT: attacker can't calculate passwords from the hashes and if server wants to see plaintext/unhashed passwords instead of the hashes, then the stolen hashes are useless.

* there are some other approaches, too (for example, digest access authentication)

The main issue with the GateHub approach is that GateHub sees your unencrypted/unhashed password and this password can decrypt master key which can be used to decrypt secret keys.

There are several solutions to this. One is to have two passwords: one for authentication and another one for decryption of secret keys.

Similar approach is to derive two "passwords" (using key derivation functions) from one plaintext password. One could be sent to server for authentication and another could be used for decrypting master key and secret keys.

 

A better approach would be to never send the password or the master key to Gatehub to begin with. Consider the following setup (caveat emptor: I quickly typed this out and haven't thought through it carefully; it's possible there's a flaw somewhere):

You want to create an account with Gatehub. You need to have a password (P), but you do not want Gatehub to know this password. Additionally, you have a wallet key (W) which you also do not want Gatehub to know.

So your browser connects to Gatehub and asks them for a random number (R, 128 bits). Your browser then prompts you for the password P you want to use and combines R and P together and uses them to generate two things:

- A public-private Ed25519 keypair (Kp and Ks respectively).
- A 128-bit or 256-bit symmetric encryption key (K).

The browser now encrypts W and any other information needed using AES with K as the key and produces an encrypted blob (B), which it signs with Ks producing Bs. It then sends to Gatehub Kp and Bs. Gatehub safely stores them along with R.

Notice that at this point, all Gatehub has a public key and a signed and encrypted blob.

The next time you need to log-in, Gatehub picks another random number (V, a 256-bit value), R and V to your browser. Your browser prompts you for P and combines it with R to regenerate Kp, Ks, and K.

It now uses Ks to sign V using Ed25519 and sends the result back to Gatehub. Gatehub knows Kp, and can trivially verify the signature. If the verification passes, this proves that you have Ks and, thus, that you know P.

It then sends Bs to you. Your browser can verify the signature on Bs, and extract B, which it can then decrypt using K. This reveals W and any other information stored in the blob.

This scheme has advantages and disadvantages.

The main advantage is obvious: Gatehub never needs to know P or W in this case - they stay within your browser. Any compromise would only leak a public key and a blob encrypted with what is, effectively, a random key of length sufficient to make brute force attacks impossible.

The main disadvantage (on top of having to implement all this - no small task) is also obvious: if you forget P, you've lost W.

 

Link to comment
Share on other sites

3 hours ago, nikb said:

 

A better approach would be to never send the password or the master key to Gatehub to begin with. Consider the following setup (caveat emptor: I quickly typed this out and haven't thought through it carefully; it's possible there's a flaw somewhere):

 

 

Quote

You want to create an account with Gatehub. You need to have a password (P), but you do not want Gatehub to know this password. Additionally, you have a wallet key (W) which you also do not want Gatehub to know.

So your browser connects to Gatehub and asks them for a random number (R, 128 bits). Your browser then prompts you for the password P you want to use and combines R and P together and uses them to generate two things:

- A public-private Ed25519 keypair (Kp and Ks respectively).
- A 128-bit or 256-bit symmetric encryption key (K).

What are the benefits of using R for calculating Kp and Ks? The only benefit of this I can see is "salting". If user uses the same password on other sites, then other sites can't calculate Kp and Ks.

Why Ed25519 and not some other standard scheme (ECDSA with P-256 curve)? Because Schnorr signatures have decent proof of security? Or did you have some other reason (performance?) in mind?

If one starts using digital signatures, then it probably makes sense to utilize the whole potential of digital signatures and certificates. That means certificates, CRLs, client authentication in TLS, storing private keys in safe storage (windows certificate store, smart cards, USB keys etc.)

 

 

Quote

if you forget P, you've lost W.

This is how it works now.

 

 

Edited by T8493
Link to comment
Share on other sites

10 hours ago, winthan said:

@T8493 Thanks for explanation, btw can we trust CloudFlare? And I think, Gatehub is having flexible SSL.  BTW, which SSL option is being used at gatehub.  I see only cloudfare certificates only. 

Why we shouldn't trust cloudflare? CloudFlare is a well established provider.

What is flexible SSL? Flexible SSL in context of CloudFlare is:

Quote

Flexible SSL: secure connection between your visitor and CloudFlare, but no secure connection between CloudFlare and your web server.

 

Edited by T8493
Link to comment
Share on other sites

I think the ideal solution would be to use multisig somehow. Make the signature of multiple trusted parties a requirement for a transaction, and have each party keep their own secrets, that are never transmitted over any wire. One or more of those parties could be a trusted agent (your "secret agent"). The service this agent offers is to know you personally, to recognize your voice and face with 100% certainty, if he calls you through video call, before signing on your (bigger) transactions.

 

Link to comment
Share on other sites

6 minutes ago, T8493 said:

Why we shouldn't trust cloudflare? CloudFlare is a well established provider.

Because cloudflare is a "man in the middle", that I do not have any contract with.

Link to comment
Share on other sites

10 minutes ago, lucky said:

I think the ideal solution would be to use multisig somehow. Make the signature of multiple trusted parties a requirement for a transaction, and have each party keep their own secrets, that are never transmitted over any wire. One or more of those parties could be a trusted agent (your "secret agent"). The service this agent offers is to know you personally, to recognize your voice and face with 100% certainty, if he calls you through video call, before signing on your (bigger) transactions.

You need something more automatic for most common scenarios. Some users trade very often (several times daily). Will you wake up this "secret agent" in the middle of the night?

 

Another idea is to have app on another (separate) machine that automatically (co)signs preauthorized transactions. For example, it only (co)signs transactions that match all of these criteria:

  • transaction type is OrderCreate and OrderCancel
  • Bitstamp.XRP/USD trading pair
  • price is not too far from the last price.

I have some kind of crude POC for this.

 

 

 

Edited by T8493
Link to comment
Share on other sites

6 minutes ago, lucky said:

Because cloudflare is a "man in the middle", that I do not have any contract with.

GateHub has contract with them.

They probably act as data processors that process data on behalf of GateHub. However, @gatehub should be probably more clear about this on their Privacy policy page. Right now it looks like they somehow forgot to mention data processors that process data on their behalf.

 

Edited by T8493
Link to comment
Share on other sites

57 minutes ago, T8493 said:

You need something more automatic for most common scenarios. Some users trade very often (several times daily). Will you wake up this "secret agent" in the middle of the night?

 this is obviously not for your day to day payments, but would be good for your savings account.

indeed, using such method could mean that i can not send such transactions in the middle of the night, which can be exactly what I would want to achieve.

unless of course your secret agent is your spouse...

 

Edited by Guest
Link to comment
Share on other sites

2 hours ago, T8493 said:

Another idea is to have app on another (separate) machine that automatically (co)signs preauthorized transactions. For example, it only (co)signs transactions that match all of these criteria:

  • transaction type is OrderCreate and OrderCancel
  • Bitstamp.XRP/USD trading pair
  • price is not too far from the last price.

I have some kind of crude POC for this.

 

 

 

That sounds like some sort of generic multi-sig service. The 3rd party would only sign if

  1. transactions are made to a predefined list ripple addresses (or e.g. what banks do, only allow transactions that you have sent earlier to the last 15 months, or a fixed list of address)
  2. only allow transactions below a perdetermined certain price
  3. allow trades between predetermined pairs, some price delimiters

The parameters would be adjustable on personal basis

Link to comment
Share on other sites

A lot of these security options seem to go against Gatehub's purpose as I understand it.
Improved back end security is always welcome but extra hurdles and steps to the front end not so much.

They are operating as the everyman's everyday wallet and trading service. I see them more as the wallet you carry in your back pocket. Adding padlocks and a car alarm to it would make it more secure but not more usable.

Perhaps Gatehub will offer some form of super secure storage service to its product line at some point, where immediate access is a lesser concern to security, but that's not the case now

Link to comment
Share on other sites

17 minutes ago, Mercury said:



Perhaps Gatehub will offer some form of super secure storage service to its product line at some point, where immediate access is a lesser concern to security, but that's not the case now

Good idea !

This is a realy basic request whan it comes down to money

I hope that someone at ripple /gatehub will take this  issue  seriously 

 

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...