Timeline for Is the following authentication scheme secure?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 3, 2011 at 7:23 | comment | added | D.W. | Brute forcing is not impossible. One can simply exhaustively try possible passwords, consecutively attempting to log in to the server. (Or, if one records the password hash, one can mount offline dictionary search.) | |
| Aug 2, 2011 at 15:12 | history | migrated | from stackoverflow.com (revisions) | ||
| Aug 2, 2011 at 12:45 | comment | added | Thomas | You're right, I missed that line | |
| Aug 2, 2011 at 12:38 | comment | added | Josh | "...are sent to the server via a TLS/SSL connection". | |
| Aug 2, 2011 at 12:35 | comment | added | Thomas | In your original post, you never specified SSL was out of the question, besides, I can't think of another method to avoid tcp sniffing besides encrypting data, maybe if you include machine specific data like computer name / or ip so when the first authentication request comes, you store the ip, every next request you can match the senders ip with the stored one. Faking tcp packets is harder then just reading data from them and reusing that data. | |
| Aug 2, 2011 at 12:17 | comment | added | Josh | The datetime is hashed into the final password, so a sniffed access of the password would only grant a malicious user a password that works for whatever remains of the minute they stole it in. And this is over SSL, I just wanted to make sure that the data sent doesn't rely on the security of SSL alone to insure that sniffing isn't being performed. Now the point you bring up about re-authentication per minute is interesting. However, I plan to require an authentication hash for each server request, so the client only needs to authenticate per request, not per minute. | |
| Aug 2, 2011 at 12:10 | history | answered | Thomas | CC BY-SA 3.0 |