Ive been asking around for some feedback on my website and one comment I received was the following
"I signed up with email#email.com and managed to active my account with http://www.mysite.co.uk/activateuser.php?email=email#email.com
You need checksums to stop it."
Can anybody elaborate on this and how I can implement them into my activation?
In theory, If I was to create a row named "rand_key" in my DB and when a user registers a random key is stored in the column, could I then use this as the activation as opposed to the email? thus making it un guessable?
You need to create a unique user key, which shouldn't be related to user data. Usually you could do something like hashing the output of a random generator function in order to make it unique and use that. Then you point them to the link:
http://www.mysite.co.uk/activateuser.php?userid=generated-unique-hashed-key
This unique user key should be added as an extra field to the table where you store your user info, or related to the user in some other way. By keeping the key unrelated to user data you make sure nobody can discover a user's key and maliciously activate/do another action instead of your user.
Then you should test the user key on arrival for some conditions:
not authorized yet - authorize
authorized already - some error
wrong key - some error
Also, there should be an expiration date associated with your user, upon which you just deactivate the user along with his key.
The person means you can activate your address by going to that url and simply putting the email address in thr url. You could do this without actually getting the activation email.
By using a checksum, you force thr user to click the link. E.g.
Activate.php?email=aaa#bbb.com&check=A1234b23
At the time of sending the email you would geneate a random code. Store this in your database somewhere. Append it to the url the user is given. When the user clicks the link, you check that the code matches the code stored for that email address. If it matches, validate the email. Else do not.
In theory, If I was to create a row
named "rand_key" in my DB and when a
user registers a random key is stored
in the column, could I then use this
as the activation as opposed to the
email? thus making it un guessable?
Yes. Keep in mind that you don't necessarily want random as much as you want unique (in order to avoid two email addresses accidentally getting the same activation code).
You could do something like:
$key = mt_rand().'-'.uniqid('', true);
echo 'http://mysite.com/activate?key='.urlencode(base64_encode($key));
That would be tough to guess and would be guaranteed unique.
Related
I am integrating a user verification feature into a plugin I am developing whereby a user must verify their email address by clicking a link sent to them.
It is based on code provided on Github
At the moment I create a 'temporary' user, then delete the user from the users table. Only after verification is the user added back into the users table.
Is there a way to disable the core user registration in Wordpress so that I don't have to delete the user, therefore it is never stored in the database until it is created by the verification code?
I am finding, quite naturally, the user IDs are skipping every one digit so that for example, a verified user has an id '1' then the next is '3'.
Thanks,
Leon
The standar way to do that is through a field in the table users that is set to true for example whenever the user have validated his email via your link.
And with this field you control that if the field is not validated you dont let them sign in on you website.
So in order to apply this you need to find the sections in your wordpress that control de sign in to put the restriction with this new field
I'm going to be more specific so you can remove the downvote...
Lets think for example that you have a field named email_verify which will just contain a 1 or a 0 if the email is already validated or not.
Then you have another field for example session_token with a sha1 or random token that must be unique for the link that will validate the email when clicking on it.
You need to have a php function that catches when someone enters that link and you do it by extracting the sha1 from the link as an url parameter and searching in your table for whoever have that session_token, when you find a record with this session_token then you turn your email_verify value to 1 meaning the email is already verified and then you turn null the session_token field so the link expires.
I'm not familiar with PHP / MySQL and Emails. And I'm pretty sure this question has been asked somewhere already, but I cannot find it. So I apologise if this is troubling and thank you in advance!
Is it possible to do something that user has to click on a link in email first before the user is added into database???
And you know how, for some websites, they have a unique web address for each email validation (Shown in red on the picture)? How do they create a webpage that's unique in for every email ?
Picture credited: https://kayako.atlassian.net/wiki/download/attachments/5734920/subs-validation.png?version=1&modificationDate=1291956283000&api=v2
Thank you a lot for the attention! If it's possible, I prefer not having straight scripts that I can copy and paste because I like to find out myself :P But please do give me some hints because I'm totally lost.
If there's anything that's not clear, please tell me, I'll try my best to clarify it!
The Registration process
User fills out a form online with basic details including an email and password, and submits the form to register.php
register.php adds user info to a temporary location, such as a pending_users table which has all the fields the user submitted along with an expiration and an activation_code fields. This code can be any random, impossible to guess value. eg: hash('sha1', mt_rand(10000,99999).md_rand(10000,99999)). Just don't do anything predictable such as hash the current time, or the username
register.php sends an email to the user with a URL that will link to activate.php and that includes the activation code. eg: example.com/activate.php?code=a2ef24... The email should also inform the user of the expiration (1 to 12hrs validity seems ok to me)
When user clicks the link, she triggers a GET request to activate.php. In doing so, the user proves ownership of the email address
activate.php gets the code from the request parameters, eg: $code=$_GET['code']. With that code, the script queries the pending_users table for the record matching that code.
If the code is found, check that it hasn't expired before proceeding. Expiration prevents someone else much later who gets in the user's account from completing the registration.
If the code is valid, capture the user details from the matching record and delete that record from pending_users table.
Write a matching record in the regular users table. Until this is done, the user could not log in because login script only checks the users table, and ignores the pending_users table.
Registration complete.
Security Note I:
For your users' protection, never store passwords in cleartext. When you receive it from the registration form (eg: $_POST['pwd'], do:
$pwd = $_POST['pwd'];
//first validate; it should meet minimum requirements
$pwd_hash = password_hash($pwd, PASSWORD_DEFAULT); // <- the hash gets stored
Later, to verify the password, do:
password_verify($cleartext_pwd, $pwd_hash);
It will return true if the password is correct; false otherwise.
Security Note II:
For your protection, never insert user supplied values directly in your DB queries. This means any value that arrives from the outside. Not just usernames, emails, passwords... but also values that you're getting back from the user such as activation_code above or cookie values or headers (eg User-Agent). Instead, learn to use prepared statements. This will protect you from SQL injection.
Not sure if it's possible to add datas in database after the validation...
When I want to do something like that, I create a data in the users table (or metas users table) like "validate".
If this data is "true", then the user already did the validation and he can use his account. If it's still set on "false", the user didn't validate his account : he can't use it.
With that, you have to make sure the account is validate when the user tries to log in, but it's not a big deal ^^
Hope it's usefull.
Those are not a unique websites, there is only one script validating the registration finalization. The incoming requests (when the user has clicked the link) are routed all to the same script by means of server side "request rewriting", so that the random token value is available as an argument (parameter) to the script execution.
What the script does: it checks if that random token value does exist in the database where it has been generated and stored before when the user actually registered.
The only thing left to do for that script is to remove the confirmation random token and/or set a flag indicating that the registered use has actually confirmed his identify (email address) by clicking the link.
Easy and straight forward. Hard to bypass, since you cannot guess what random token value has been generated for what registered user without receiving the email. However take into consideration that it is trivial for an attacking script to use anonymous email services (one time email addresses) to receive and evaluate such a confirmation request, if the process is known to the attacker.
I'm adding an option for my users to change their email, and I'm thinking what is the best way of doing it in a safe and fool-proof manner.. so far I have the following options
1) When user changes the email, system stores in a temporary column in the database and sends an email to the new one, requiring the user to click the link to confirm it and only then, change it (I would need 2 extra fields on my DB - temp_email and email_token)
2) When user changes the email, system would gather data from AccountID and New Email, encrypt it and send it to the new email.. when the user clicks the link, system decrypts it and changes accordingly.
I really like the second option, since it does not require saving extra fields on the database.. so my question is.. which one is a better solution? Or perhaps a third one..
I have two fields in my users table: recovery_hash and recovery_time that are updated when a user changes something. I put in a random hash and the current time.
I then send an email to that person (in your case, to their new address), and in the link is the hash (http://foobar.com/verify/randomHashG03sHere). The user clicks the link and it goes to a verify script on the server - which validates the hash and then checks to see if the current time is within an hour of the recovery_time. If both checks validate, I make the change, which, in your case would be updating the users email field with their new email address - which you could store in a separate table, or even in the same users table as a new_email field.
Since you're anticipating the user wanting to change things, you could just store the new email address in a separate table, such as users_temp.email and then update the users table with that new value after it's been validated.
You could just create another table to deal with temporary e-mail addresses (e-mail + AccountID + token + timestamp (possibly)).
I would highly avoid option 2. Keep all your data local on your server! In case someone breaks your encryption he can mess up your entire database or webservice. Especially credentials or email-addresses should never be outsourced. Option 1 is much more recommended, though the data could also be stored in a different manner.
I would like to have a aspect of my site that users can use to sign up for a newsletter.
I am not 100% what the best way to accomplish this task would be.
What I can think of is very simple:
One input with a submit button, the user enters their email address there.
A random 32 character hash is generated and stored along with their addess within a mysql table.
Am email is sent to the address containing the hash and asking the user to enter their email address and the hash on a page that checks it against the mysql table.
If correct the email becomes active by defining an additional entry on the table.
That is about as far as my knowledge of the two can take me...
What i would like to accomplish, is in the confirmation send the user a link that they can click to confirm their address... something like http://www.mysite.com/users/newsletter/?user=aGuy&confirm=blahBlah.
But I really do not know where to start with something like that... And as i understand it, allowing mysql queries in such a manner is not secure...
Would someone be able to provide me with some more information regarding this matter?
This being in the form of suggestions or links to tutorials that may cover something like this.
Thank you for taking the time to read this!!
You're close.
When a user submits his email address, insert it into the database. At a minimum, the table should 4 fields (id,email,verified,key). The id is just a surrogate key (auto-increment). verified should default to false, and the key shouldn't really be a hash but a randomly generated string -- anything that's hard to guess. Hashes are deterministic, so hashing the user's email address with an md5 wouldn't make for a good key if someone figured out what algorithm you were using. A random element is better suited, but again, anything hard to guess will serve just fine.
The email should contain a link that holds the id and the key. You use the id to look up the record in the DB (since it's unique) and then check that the key in the URL matches the one stored in the database (key doesn't have to be unique). If they match, set verified to true, and voila.
For bonus points, you can store a date that the verify email is sent, and you can prune out unverified emails after 24 hours or so.
Your description of the flow is fine, just start implementing it.
The sfGuard package implements a similar flow, check out their source code and database design.
Working on a web based "buying and selling" application with PHP MySQL where users can post adverts for items and services.
Before a new advert is displayed on the system there must be a method of verification to ensure that the user provided email address is correct, and that the advert is legitimate.
I want to send the creator of any new advert an email containing an url which directs to a page whose primary functionality is to receive a posted variable, $advert_id, and to select the advert from the db for updating / editing / deleting.
This variable is embedded in the url with PHP syntax
ie. [http://www.example.com?content=modify_advert&advert_id=2246317].
This part is quite simple to implement, BUT, if a user was to modify this variable called "advert_id=2246317" to any other integer, they can access other posts/adverts in the system.
The system is advert based, and users dont need an account or login to post, so we cannot prompt for a login at the point of verification which would have been convenient.
Any ideas as to how we could protect the adverts/posts in the system from being accessed via the aforementioned url???
Any suggestions?
If visitors will only be viewing that page from the link you send via e-mail, you can include a hash in that address instead of the advert_id — essentially a random, one-time password.
One common and "often good enough" trick for generating such a random password is to take a single, secret, truly random string (I usually use grc.com), concatenate it with the unique advert_id, and hash the whole thing with, say, SHA1(). Like so:
UPDATE advert SET advert_hash = SHA1(CONCAT(advert_id, 'lots-of-randomness-here'))
You could even vary this by adding time(), or (better still) a random number to the end. The outcome is a 40-character string stored in your database that nobody could possibly predict (without knowing the secret data you used to generate it).
For example, I might get this instead of advert_id=1:
f2db832ddfb149522442c156dadab50307f12b62
If I wanted to sneakily edit advert_id=2 (which somebody else created), I'd first have to guess that the hash is this completely different string:
e5c6a3a9473b814b3230ee7923cbe679fcebc922
So, include that in the URL instead of the advert_id (or, if you like, in addition to the advert_id), and suddenly your users are powerless to ruin other people's content.
You could add a salt to the id and then hash it.
sha1($advert_id . $salt);
Send this to the user in the URL instead of the advert_id, and store it in your database, along with the advert_id.
Then when they click the link, you find the matching advert for that hashed value.
Making the salt a secret is how you keep users from 'guessing' a valid URL that will let them modify an ad that they did not post. Perhaps you could use the users email address, the time posted and/or a name or something that the user enters when they make a post.
Generate a GUID as the advert ID so simple ID guessing attacks are unlikely to succeed.