3 ms·

Twitter is a platform used widely by some of the most powerful people in the world and in the US government. As a result, there is plenty of justification and p

Twitter is a platform used widely by some of the most powerful people in the world and in the US government. As a result, there is plenty of justification and precedent for said gov't to regulate their security practices and procedures. To illustrate this point, I doubt you'd have any sympathy for Twitter if they had been sending their passwords over http. Now, I don't think the government is prepared to do this proactively and effectively, but the idea of a telco that advertises resilience to hacks (whether through social engineering or technical incompetence) sounds like it would be quite appealing to a growing segment of the connected world and whatever such promises that find success in the marketplace might be used to inform legislation or regulation, eventually...

saghm 6y ago
> To illustrate this point, I doubt you'd have any sympathy for Twitter if they had been sending their passwords over http This is probably off-topic, but companies shouldn't even be sending the passwords over HTTPS; passwords should be hashed client-side and then the hash should be sent to the server (preferably over HTTPS).
- ribosometronome 6y ago
  Wouldn't that allow for a compromised database to leak the information a nefarious user needs to log into accounts? Compared to needing to find a collision if a database of hashes leaked?
  - nicoburns 6y ago
    I think client-side password hashing is generally in addition to server-side hashing. Not instead of it.
- helsinkiandrew 6y ago
  Can you elaborate on how this makes things more secure (assuming HTTPS) Surely if the server accepts a client side hash of a password, then the hash has become the password
  - namibj 6y ago
    At that point you can do key derivation to get an ed25519 private key from the password and a server-supplied salt (specific to that user), after which the client signs a challenge the server supplied with that private key. When the password was set/changed, the corresponding public key was stored on the server.
  - mewpmewp2 6y ago
    Off the top of my mind. Maybe it could be something like that: 1. Api gives user a fixed salt. 2. User types password into input. 3. Client hashes and sends hash to server. 4. Server has another salt and uses the client sent hash to hash it again. 5. This final hash is compared what is in the database. This way server never has knowledge of the original PW and it's never sent over the network. This reduces for instance the chance of password getting logged in the service etc.
    - helsinkiandrew 6y ago
      But in that case the hash sent to the server in stage 3 is always the same and behaves like a password - capture it and you can use it again elsewhere.

saghm 6y ago

> To illustrate this point, I doubt you'd have any sympathy for Twitter if they had been sending their passwords over http This is probably off-topic, but companies shouldn't even be sending the passwords over HTTPS; passwords should be hashed client-side and then the hash should be sent to the server (preferably over HTTPS).

ribosometronome 6y ago
Wouldn't that allow for a compromised database to leak the information a nefarious user needs to log into accounts? Compared to needing to find a collision if a database of hashes leaked?
- nicoburns 6y ago
  I think client-side password hashing is generally in addition to server-side hashing. Not instead of it.
helsinkiandrew 6y ago
Can you elaborate on how this makes things more secure (assuming HTTPS) Surely if the server accepts a client side hash of a password, then the hash has become the password
- namibj 6y ago
  At that point you can do key derivation to get an ed25519 private key from the password and a server-supplied salt (specific to that user), after which the client signs a challenge the server supplied with that private key. When the password was set/changed, the corresponding public key was stored on the server.
- mewpmewp2 6y ago
  Off the top of my mind. Maybe it could be something like that: 1. Api gives user a fixed salt. 2. User types password into input. 3. Client hashes and sends hash to server. 4. Server has another salt and uses the client sent hash to hash it again. 5. This final hash is compared what is in the database. This way server never has knowledge of the original PW and it's never sent over the network. This reduces for instance the chance of password getting logged in the service etc.
  - helsinkiandrew 6y ago
    But in that case the hash sent to the server in stage 3 is always the same and behaves like a password - capture it and you can use it again elsewhere.