I know this question has been asked many times, but I have a little different spin to it. It's a two part question.
First, I am implementing an auto login and I'd like to know where any holes are in my workflow.
Second, I'm unclear as to how a hacker would use the information they stole to compromise a system.
When a user is required to enter a username and password every time he wishes to login, the only information stored client side is a cookie containing the
session id. Now this is prone to
session hijacking, which works on the principle that being client side, a user has full control of the session id sent to the server and in a non-secure environment, this is transmitted via HTTP (w/o any encryption). If a malicious user managed to get a hold of another user's session id, he could "hijack" that user's session.
There are ways to prevent or discourage session hijacking. One method is to whitelist the IP Address and/or browser information in the session. If the session conflicts with the "whitelisted" information, the session has been compromised.
Using your "auto-login" logic, your server only requires a single hashed string to gain access to a user's account. Since this hash is stored client-side, a user can "submit" any string they want in place of the hash. If the connection is not secured (HTTPS), and the network the user on is not necessarily trusted, a malicious user can intercept the hash string. They could theoretically use that single hash string to login as the user.
At this point, your hash string, no matter how strong the algorithm was to generate it, is simply the new "username/password".
Most of the holes in the security depend on an insecure connection. If the connection is well-secured with a modern cypher-suite, I don't believe you'd be prone to the same issues.