So, I've created an authentication system. Poured over it for any kind of security flaws and tested the crap out of it. I think it's fairly secure, but there is one "different" by-design aspect of it that's not usual of a web authentication system. 

Basically, I wanted to make it so that authentication could be done without keeping track of each user's session. This means less load on the database, and trivial to scale and cache. Here are the "secrets" kept by the server:


A private-key is kept in the source code of the application
A randomly generated salt is kept for each user


To make it sessionless, but making forging cookies not easy, this is the format of my cookies

expires=expiretimestamp
secret=hash(privatekey + otherinfo + username + hashedpassword + expires)
username=username


(with otherinfo being things like IP address, browser info, etc and with hashedpassword=hash(username + salt + password + privatekey) 

My understanding is that forging login cookies (not cracking the passwords) requires:


Source code access to the application, or a way to trick it to spit out the private key
Read-only access to the database to get the salt and hashedpassword


Whereas the traditional session method requires:


Write and read access to the database (to inject the session, or trick the web app into doing it for you)
Possibly source code access depending on how it works


Anyway, does this seem overly insecure to anyone? Are there any ways for me to improve on it and make it more secure(while keeping with the stateless/sessionless model)? Are there any existing authentication systems which use this stateless model? 

Also, the hashing method can be basically anything, ranging from SHA256 to Blowfish


Question: Dropbox Webhooks API
Answer: There's no real way to detect a rename (versus a delete and an add) via the Dropbox API. You can use heuristics (like whether the new file has the same contents as the old file and was created around the same time as the old file was deleted), but those are just going to be guesses with varying levels of accuracy.

Also, there's currently no way via the API to see which user modified a file in a shared folder.

UPDATE: The Core API now includes (in beta) the ability to see who last modified a file in a shared folder. See https://www.dropbox.com/developers/blog/101/new-in-beta-shared-folder-metadata.