We needed to generate secret tokens for the app, me being as curious as I am, asked what encryption algorithm they were using, little did I know the the answer would be a random string generator.

Every day further from god.

And what is the problem with that?
If you are using securerandom, and a non fixed seed - there should be no problem.

@magicMirror maybe, I’m not a security expert, but after some investigation I found that most secret token are generated with a encryption algorithm so definitely there must be some security implications on that.

@magicMirror but honestly what bother me the most is that there no even a validation that the secret token is correct or anything, it will take anything you pass to it, even if it is “a”.

Is that also not a problem? Not being sarcastic btw haha

Sounds a security breach to happen at some point if that's what they use.

@eptsousa to the best of my knowledge, most security tokens use hashes of the time stamp + a salt + the user's id (+ maybe something random, i forget).

encryption's not the right word here, because if something's encrypted, it can be decrypted with a key.

hashing is like encryption, except the data cannot be decrypted. that's why it's used for tokens. you never need to decrypt a token.

we hash the user details, timestamp, and a salt to create unique tokens. random numbers/strings could just be equal to each other, so if you got the same token as someone else, one of you would have access to the other's account.

it is theoretically possible that two hashes might be the same, but i think there's no known collisions with sha.

if it's a long enough random number and securely generated, then there really isn't much to worry about, as the chances of two of the same tokens are very low.

but to your second comment- you definitely have to validate them. that's the flaw.

@calmyourtities thanks for the clarification, it’s much clearer after the explanation, if you don’t mind me to ask, so it would be okay to generate a random 128 characters string because in practicality would be too long to brute force it?

@eptsousa a token is like a temporary password that's sent to the server. if someone tries to brute force a token that's even six lowercase, alphanumeric characters long they probably won't get it, as the server can usually say "you've tried an incorrect token 5 times in the past minute, your ip is banned from this server for a day," in the same way you get locked out of an account when you type in the password wrong too many times. with only 5 random guesses allowed, the attacker only has a 5/(36^6) chance of getting the token right.

if you're going to bruteforce, you need to have the hashed/encrypted data locally.

i think what you may mean is that what are the chances two accounts get the same token, which is also very low. i don't know if this is correct, but i think the chance would be the x / (y^z), where x is your number of users, y is your number of different possible characters (56 for alphanumeric ) and z is your length of token (128 in this case), so i think it's good.

@calmyourtities thanks so much dude, a bit less ignorant now haha.

System Entropy will take care of it lmao