Timeline for How does a password authentication over a TCP protocol actually work?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 9:49 | history | edited | CommunityBot | Commonmark migration | |
| Jul 12, 2015 at 17:06 | comment | added | Gerald Davis | There is nothing wrong with sending "plain text" password inside an encrypted tunnel (TLS) to an authenticated server. Certs are obviously a superior choice (especially if encrypted w/ password derived key) but if limited to authenticating by credentials (username & password) client side hashing doesn't magic away the problems if the server is compromised. | |
| Jul 12, 2015 at 15:26 | vote | accept | Peter | ||
| Jul 6, 2015 at 17:54 | comment | added | Rob | Though it would be ideal, TLS isn't solving this in practice because the server will almost never require a certificate from the client to prove its identity. SmartCards that supply these client certs work, but are a logistical headache outside of a centralized environment (like the military). Because passwords may be reused among sites, it's also not a good idea to send the plain-text password to an authenticated server. But this is often done because many backend systems are not design to securely delegate challenge/response up to the user (ie: they want a password). | |
| Jul 6, 2015 at 15:36 | comment | added | user79537 | Only thing I have to add is SRP is a zero-knowledge protocol. Only the client knows the password. This is particularly useful in the instances you described. | |
| Jul 6, 2015 at 14:32 | history | edited | Gerald Davis | CC BY-SA 3.0 | added 1556 characters in body |
| Jul 6, 2015 at 12:38 | history | answered | Gerald Davis | CC BY-SA 3.0 |