0

I noticed the following site: nightchamber.com

A user account is automatically generated on first visit and keyed against a uuid, the id is then stuffed into the session and used to make a link the user can bookmark to get back to their "account". As long as that link/id remains secret, the user has a unique account to use with no effort on their part.

Are there any immediate drawbacks using this method for a super-fast login and/or signup?

1

If it's a well generated UUID (e.g. not just a sequential number jammed into something that looks UUID-y), and the site doesn't contain any particularly sensitive data (e.g. credit card payment info, personal addresses, etc.) it's probably not too bad.

The main flaw is the one you mentioned: if it's not secret, anyone has access. That implies that HTTPS should be used, with cache control headers set to prevent intermediate caches from storing the URL. There should be a method of deactivating a given link, upon verification using a different method (e.g. email them a deactivation link), in case of a noticed leak.

You would also expect the site to implement reasonable precautions against changing other details, such as requiring a password before you could change the registered email address, or also demanding a cookie.

Wouldn't want to use it for anything sensitive, and certainly not for anything involving payment, PII or health related info, but for an online game, or chatroom, or similar (I've not visited the link!) it's not dreadful.

| improve this answer | |
1

There are several methods to generate UUID. The method 4 involves using 122 bits from a random generator. If that generator is cryptographically strong, then the UUID is a good secret key. But it can be hard to ascertain whether a specific implementation of UUID generation uses method 4 with a strong PRNG. In general, UUID are meant for uniqueness, not unpredictability. For a secret authentication token, you really need the latter. For example, if "type 1" UUID are used (combination of the system MAC address and current time), then attackers can easily infer what UUID your system will produce for other users.

That being said, in a given system, you could manually use a strong PRNG to get a 128-bit unpredictable sequence, which would be a sort-of UUID with the needed characteristics.

Providing the authentication token as part of an URL that users can bookmark has an other issue, which is that users will bookmark it. Storage of secret values on a desktop computer takes some care. Browsers apply that care for cookies, not for URL. In particular, URL may be displayed (and typically will). This would be a problem in exactly the same sense that you would not like a Web page that shows your password: people having a glimpse at your screen may gain too much information.

Also, bookmarks are synced up (when you use such a feature) while cookies are not. Accessed URL also make it your saved "history". This is part of the "extra care" bit I was talking about. Generally speaking, URL tend to travel and be copied a lot more than cookies, and are less protected against unwanted inspection. This makes them less appropriate for secret values, such as an authentication token.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.