Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
magicMirror7398167dAnd what is the problem with that?
If you are using securerandom, and a non fixed seed - there should be no problem.
Berkmann181025167dSounds a security breach to happen at some point if that's what they use.
calmyourtities23079166d@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.
calmyourtities23079166d@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.
3rdWorldPoison868141dSystem Entropy will take care of it lmao