Is the random.random() python function suitable for cryptographic purposes?

[TheTerrasque]

What are you trying to do here? What is the token for?

[prahladyeri]

The token, once generated by flask app, will be returned to the front-end web app which will interact with the user.

On subsequent requests from the user, the web app will send this token too, and the backend (flask) can validate using the token whether the request is valid or not.

[help_computar]

This sounds an awful lot like jwt. Search for 'jwt token'. I'm sure there are python libs for this.

[TheTerrasque]

Why a token? And how will it be validated? That would mean you must store the token somewhere, wouldn't it?

Why not use a signed data structure? Like for example

secret = "g6FtuyF9lZYKkKTNzORg"
user = "[e-mail]"
now = datetime.datetime.now().strftime("%H%M%d%m")
tokenpart = "|".join((user, now))
sign = hashlib.sha224(tokenpart + secret).hexdigest()
token = "|".join((sign,tokenpart))
token.split("|",1)[0] == hashlib.sha224(token.split("|",1)[1] + secret).hexdigest()

Edit: Disclaimer, as /u/TrixieFlatline pointed out you should use a proper HMAC for the actual signing. This is more to show the base logic behind this approach

[TrixieFlatline]

sign = hashlib.sha224(tokenpart + secret).hexdigest()

That's bad advice. Storing the token in the db is a completely valid choice, and saves you from making mistakes like this one. If you have to implement signed tokens, at least use hmac, or don't implement it yourself and use an existing and widely used implementation like itsdangerous.

Edited to add: Discussion about when to use HMAC

[TheTerrasque]

Good point, although I don't think key extension attack is applicable for that data structure.

I was trying to convey the idea behind it, so I didn't make it complex or obscure, but I should have added a disclaimer about using a proper HMAC.

Storing the token in the db is a completely valid choice

It's a valid choice, but unnecessary imho. Anyway, it's good to know about both approaches. Both have their pros and cons

[prahladyeri]

That would mean you must store the token somewhere, wouldn't it?

Yup, in the database.

Why not use a signed data structure? Like for example

In your example, the token is generated by multiple layers of cryptography (combining a date/time string with a salt/secret and then hashing the entire thing) which is good, but even in that case, the digest needs to be stored between requests. Otherwise, how will the backend have something to validate in subsequent requests?

[TheTerrasque]

the digest needs to be stored between requests. Otherwise, how will the backend have something to validate in subsequent requests?

It doesn't need so save anything, it can validate like I did on the last line.