3 ms·

Very good point. As a reporter of Gizmodo he might have tried the hack. I do believe though that sending a password "in the clear" over SSL is totally sufficie

by pilif 14y ago

Very good point. As a reporter of Gizmodo he might have tried the hack. I do believe though that sending a password "in the clear" over SSL is totally sufficient. SSL was designed exactly for sending sensitive information like passwords. We can't blame Apple for not designing a protocol (it might be just plain HTTP basic over SSL) with people in mind that turn off SSL security in order to get access to paid content without paying. I was voicing this exact concern here: https://news.ycombinator.com/item?id=4240124 https://news.ycombinator.com/item?id=4240124

0x0 14y ago
In this case you are betting on captured SSL traffic never being able to be cracked in the future, offline. (Consider: Someone logs SSL traffic and waits for the next Debian OpenSSL bug (DSA-1571-1) to be revealed) I think it would be a great improvement to have some kind of challenge-response nonce/timestamp hash thing going. So that even if the plaintext of an SSL connection were to be revealed at some point, you couldn't deduce the password-equivalent.
- pilif 14y ago
  The application shouldn't have to work around flaws in the underlying protocol, especially when a solution exists (perfect forward secrecy http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se... provides a good overview) The problem with challenge/response and nonces is that the server and the client both need to have access to something secret to encrypt the nonce with. This usually means storing the plain text password on the server or at least a hash of it which then would be used to encrypt the nonce. But this also means that when your user database gets lost, all accounts are instantly compromised without the attacker having to do any kind of brute-forcing. Unless you notice an intrusion immediately, the damage that can be done in such a configuration is way bigger than if the server gets the secret thing from the client and does the hashing there, because now an attacker has to individually brute-force the various accounts (keeping at least those who chose a strong password safe). Even if perfect forward secrecy was not doable, I assume it's far less likely for an attacker to brute force my SSL private key than it is for them to acquire my user database - not that I want that to happen of course.
  - 0x0 14y ago
    That's a good point. On the other hand, with the ECDHE / PFS scheme, aren't you still at risk for an implementation specific bug like the Debian incident? (I.e. the server or client only ever picks the a/b factors from a very limited range?) Anyways, your suggestion sounds much better than my initial nonce suggestion. :)
- tedunangst 14y ago
  Everybody is betting on captured SSL traffic to remain secure.

by pilif 14y ago

0x0 14y ago

In this case you are betting on captured SSL traffic never being able to be cracked in the future, offline. (Consider: Someone logs SSL traffic and waits for the next Debian OpenSSL bug (DSA-1571-1) to be revealed) I think it would be a great improvement to have some kind of challenge-response nonce/timestamp hash thing going. So that even if the plaintext of an SSL connection were to be revealed at some point, you couldn't deduce the password-equivalent.

pilif 14y ago
The application shouldn't have to work around flaws in the underlying protocol, especially when a solution exists (perfect forward secrecy http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-se... provides a good overview) The problem with challenge/response and nonces is that the server and the client both need to have access to something secret to encrypt the nonce with. This usually means storing the plain text password on the server or at least a hash of it which then would be used to encrypt the nonce. But this also means that when your user database gets lost, all accounts are instantly compromised without the attacker having to do any kind of brute-forcing. Unless you notice an intrusion immediately, the damage that can be done in such a configuration is way bigger than if the server gets the secret thing from the client and does the hashing there, because now an attacker has to individually brute-force the various accounts (keeping at least those who chose a strong password safe). Even if perfect forward secrecy was not doable, I assume it's far less likely for an attacker to brute force my SSL private key than it is for them to acquire my user database - not that I want that to happen of course.
- 0x0 14y ago
  That's a good point. On the other hand, with the ECDHE / PFS scheme, aren't you still at risk for an implementation specific bug like the Debian incident? (I.e. the server or client only ever picks the a/b factors from a very limited range?) Anyways, your suggestion sounds much better than my initial nonce suggestion. :)
tedunangst 14y ago
Everybody is betting on captured SSL traffic to remain secure.