Mobile application authentication using UUID

Question

I write back-end code for mobile applications. I am needing to write the code for authentication and the simplest yet secure solution I can think of is:

• When user signs in, device sends username and password to server
• If credentials are valid server returns token
• User sends token with every request

Details about token

• In Java I can create token as UUID (which is created using SecureRandom under the hood)
• I write this token into DB in users table in user row
• On every mobile application request I make SELECT ... FROM users WHERE token = ? and check if current user is allowed to perform operation
• Periodically I change token in users table to expire previous token

Is it good enough?

It seems secure, but I'm not a security expert so I thought I'd ask here. I haven't seen this solution before and I am wondering why.

• Someone would complain about performance because of hitting DB every time but in real application every request generates a lot of SQL queries so one more shouldn't be a problem.
• Someone could complain about UUID, but as far as I know in Java UUIDs are presumed impossible to guess because of the implementation of SecureRandom.

Is this solution secure or are there any holes I couldn't see?

Answer 1

I have one main concern with your setup: You should hash the UUID tokens! Otherwise, if your database leaks all accounts will be exposed. Given the amount of entropy in a securely generated UUID, a simple hash function as SHA-256 will do the job.

A few minor points.

Using a UUID as an authentication is not wrong from a security perspective, as long as you are 100% sure that it uses a secure random source (and the Javadoc seems to agree with you on that). To make the code more explicit, personally I would generate the token directly from the random source without mixing in any UUID. But that is mostly to make the code cleaner.

Make sure that you are using a version 4 UUID. The other versions are not random!

Also, I would keep the tokens in a separate table and not in the users table. But that is more about database normalisation than it is about security.

You should think about when you expire tokens. If you have some kind of log out feature, the token should expire when the user log out. In the same way, if the user is logged out when the app is closed, the token should expire when the app is closed.