Sauth

welcome to the crazy world of ideas that probably won't go anywhere, but sound sexy to me

Sauth is a name for the Stupid/Sane Auth system I've thought about a couple times (sometimes in crazier incarnations, see ["Auth"] for an example), which uses Public Keys for authenticating to a Server.

Rationale

Currently the state of some password/hash-based auth systems on the Internet are relatively Insecure, allowing people to exploit it rather easily, some examples of this are:

• Bruteforcing: it's a rather weak argument I know, cause supposedly it'd take a long time to bruteforce a password so it hashed to the same thing, but it's still possible (I realize pubkeys can also be bruteforced, and you could even say it's more convenient than bruteforcing a non-local server)
• dictionary attacks: in the same area as bruteforcing, but you try words out of a dictionary instead of random strings of characters, this makes it easier to get access to the accounts of people who choose simple words for passwords.
• Packet Sniffing: if people between you and the server can listen in to the conversation they can get your password (or password hash, if the hashing is done on the client side), which can be used by them to login to that site and others (if the pass transferred over the wire), note this isn't specific to passwords, anything where the server expects the same value over multiple connections would theoretically allow someone to sniff and resend a new request doing something else. (SSL and TLS solve this mostly I think (though I havn't looked over them too much), by encrypting data over the wire).
• some things (TBSource for example) keep a cookie around that contains your password hash to check if you're authenticated, this along with XSS or some way to get the passhash of a user allows you to easily harvest accounts. (again, this is partially because of constant-ness of the data expected)
• Partially because of the last 3 points and partially for other reasons I imagine (for example people phishing or not being able to trust some sites with a global password) users are encouraged to use different passwords on different sites, this gets slightly annoying and there are tons of password managers out there, including some included in browsers (those infernal "Remember This Password" message boxes in firefox).

also, while not strictly related to password based auth (I believe standard http auth doesn't make the server do them) one day I was looking at the TiT source and I realized that there's really no reason to actually care about sessions on the server-side, the code for sessions on the server-side is typically overly complex, and if you can change the clients to send some non-constant data that the server can verify on each request the server doesn't need sessions, it becomes stateless in that regard. (technically the original TBSource is somewhat stateless, but it doesn't check it uniquely every time, someone can still ease drop and use your passhash themselves)