Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

Comment: Re:Responses (Score 1) 242 242

You don't encrypt the UUID. It's just a verification to make sure they know the UUID, which is universally unique, generated by you, and sent only to your database and to their email address. All this does is establish that they have access to the email address they supplied. If you do as I suggest and tie this UUID directly to the user entry, an attacker can't do anything with this UUID without ALSO knowing the user's login and password. Clicking the unique link or knowing the UUID is useless unless you can also login as the user to access their row in the user table.

For password resets, you generate a random password and salt, set it to immediately expire, and then tell the user that password. You leave the old hash and salt in place - the new stuff goes in separate columns until the switch is done by the user. This prevents users from being unable to authenticate if an attacker merely requests a reset, or if you trigger an expiration due to whatever policies you have in place.

Your login page should authenticate the user (using the original password OR the new temporary one). If the user used their old password and authenticated successfully, you can ignore the reset. If they used the temporary password, block all authorization until a new password is supplied by the user (only let them get to the password reset page).

On the password reset page, ask for a new password. Double check hash(newpass+oldsalt) against the stored temporary hash (do the same for the old regular hash too, if you want). If it's a match, the user is dumb and entered the temp (or old) password. If it's not, you generate a new salt and store hash(newpass+newsalt), store newsalt, reset the password expiration date, blow out the temp password, etc.

The trick here is telling the user the temporary password. This is often done with a unique link (using another UUID) that automatically skips the authentication portion and goes straight to the password reset portion for that user. This is extremely fucking dangerous because anyone with access to the email address can hijack the user's account. Despite this, this is how most site on the internet do it. Sending the temporary password in plaintext or not makes no difference because sending the link in plaintext is functionally equivalent. Your security at this point is hoping the legitimate user made the request, is the only one with access to the email address, and the narrow time window in which the temporary password / reset link is valid.

Security questions, pin numbers, RSA clocks, text messages, heuristics (matching IPs, browsers, etc.) all provide more security, but are useful against a MITM attack or cover the scenario where a user forgot the security answer, doesn't know their pin, lost the RSA clock (dongle or phone), changed phone numbers, moved, etc.

Comment: Re:Responses (Score 5, Informative) 242 242

My site, on account creation, generates a password and sends it to you in email in cleartext before putting it in the DB. In that email is a link to reset the password; you can't log into the rest of the site until you've done so. The updated password (and the original) are stored encrypted in the DB.

If anyone has a better suggestion, I'm all ears.

Don't send the fucking password in plaintext.
Don't store the fucking password. If your database/application can read it, then it's decrypted at some fucking point. Don't fucking do it.

User creates account.
User provides password, username, email, etc.
You generate salt.
You generate a UUID (emailverificationUUID).
You create DB entry with username, email, HASH(password + salt), salt, emailverificationUUID, emailverified (0).
You email the user "Your account has been created, please click this link to verify your email address.".
Link contains the UUID. When clicked, the site performs normal login processes (prompt login if not logged in already) and then verifies that the UUID matches the UUID stored for the logged-in user, and sets emailverified to 1 for that user if so.

Comment: No (Score 1) 56 56

Very soon after Minecraft launched, we noticed teachers bringing the game into their classrooms

Often inspired by the passion of their students, they started using Minecraft to design history lessons, teach language classes, explore mathematics, physics, computer science, writing, and more.

Bullshit, bullshit, and more bullshit. I don't doubt that teachers have in fact used Minecraft for these things, but they're certainly not designing lessons, teaching classes, or exploring subjects. They're faffing about with Minecraft and the students don't benefit from it.

Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who, "Androids of Tara"