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.

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.

LOOOOOOOOOOOOL
You're SO MAD!

Web support in apps is for cows, you are all cows, moo?

Mad cuz bad? Yeah, mad cuz bad.
Fuck off retard.

FROSTY PISS
<SUBJECT> IS FOR COWS YOU ARE ALL COWS MOO
HAPPY <DAY OF WEEK> FROM THE GOLDEN GIRLS

There's not a chance in hell that "myhouse_optout_nomap" would work.
You can either do "myhouse_optout" OR "myhouse_nomap". And they'll still ignore your preference.

They could also shout it from a mountaintop. There's no _optout option for that.

Yes I would.

Seriously, if you have enough cash and connections to even think about starting a company, or even doing one of these new-fangled "startups", then you're better off than 95% of the country and better of than 99% of the world.

Might want to look up every single failed "Edutainment" attempt in history.

I'm guessing you've never taught something to someone in an effective manner.

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.

Testing, let alone QA testing or MORE testing, is NOT the Google way.

Assholes as a Service