I'm developing an application that requires authentication with devise/rails and it was decided to allow users sign in without email confirmation. However, after a deep thinking this odd workflow came in mind:
What if someone registers with my email, starts using it and later
I decide to join the app with my stolen email? The guy did not
confirm, but should I keep his account, block it or remove it?
(side note: email must be unique)
As the designer of the application, you are in control. You can handle that situation how you would like.
I'm not sure how facebook deals with 'unconfirmed' account creations. I would imagine that they allow whoever registered to check their e-mail and click the confirmation link within a certain amount of time - after which that e-mail becomes available for use by other users. This makes sense to me, as this would prevent people from spamming the site and effectively 'e-mail blocking' legitimate users from registering. If you forever allow unconfirmed accounts to sit and 'use up' e-mails, you could run into the following situation:
A malicious user creates thousands of 'fake' account registration attempts with bogus e-mails. These e-mails sit and wait forever to be confirmed, but never will be because they don't exist (yet), acting as 'in-use' e-mails. Some time later, a legit user happens to create an e-mail account with GMail or whoever that happens to match one of the 'bogus' e-mails submitted by the malicious user earlier. This legit user is then unable to register his or her e-mail with your service because the malicious user has 'e-mail blocked' this address.
My personal opinion is to give the registrant a certain amount of time to confirm their address as legitimate, and if they never confirm within that time frame, just discard the account creation attempt.
I've a very similar problem and the solution I've arrived (not implemented yet) is to make the user choose the email he want if there is not other confirmed user with that e-mail.
Once registered the user will be uncorfimed/nonactive and will receive a confirmation e-mail, when it will follow the link it will confirm his e-mail and other can't use it anymore.
Most of these sites require you to verify your email by sending you an email link. Only afterwards can you create an account. This handily sidesteps the problem of someone trying to steal someone else's email: unless they can log into your email account, they simply cannot.
Do you have a 'resend confirmation email' action (you should) or 'password forgotten' action (you should)? With both I could reclaim the account with my email address as only I have access to my emails.
Also think about the case of the user who creates an account, forgets about it and creates another account with the same email address.
Related
I'm writing an ASP.NET MVC application, which uses the Membership database to store user registrations. I use email addresses as usernames. When a user registers in my app, I send out an email-confirmation to the address they have used during registration. i.e. I send out an email with a link, which the user is supposed to click, to verify that the address belongs to him.
Until that link is clicked, the account remains 'Unconfirmed' (i.e. EmailConfirmed column equals False). Which means, the account is created, just not active.
How do I deal with a hacker who brute-force creates accounts? I see two big problems here:
Ever-increasing size of the Membership database. A single user, from
a single computer is not a threat, but what if he has 'zombie'
computers?
If User1 creates account with User2#example.com email and
User2 ignores the activation email, the account will essentially
remain locked (unconfirmed), but existing. If User2 decides later to
actually create an account, they can't use their email to register
(account already exists) and they can't Reset Password either -
because even if they reset the password, that does not necessarily
Activate the account.
As for 2) I see a couple of options:
Set expiration date on unconfirmed accounts - i.e. allow the username/email to be claimed again, if the email is not confirmed with 24hrs
Modify my Reset Password method to also activate the account, if it has not been activated. Is that a good idea? I mean, the person would receive an email for that, which is essentially a confirmation, if they click the reset password link in it.
Anything else?
What about 1)? How do I protect myself against bulk create of accounts? Aside from limiting 1 account per IP, per day, using code.
One simple way to deal with this kind of problem is crude but effective.
I usually add an additional field to the form that doesn't form part of what I need - but has a legitmate sounding name like 'Company' - and then I hide it from screen view using CSS. Real user's will never see this on screen, but a bot crawling through the HTML will find it.
Then, when the form is submitted, first I check to see if that form field has a value. If it has - I stop the page from executing any further or just return an HTTP Error as in 99.9% of times only a bot would have filled out that field - not a real user.
//anti-bot measure
if (!String.IsNullOrEmpty(Company.Text))
{
HttpContext.Current.Response.StatusCode = 400;
HttpContext.Current.Response.Status = "400 Bad Request";
HttpContext.Current.Response.End();
}
//carry on processing the form...
I've been using this technique on forms for several years and it's been extremely effective!
I am trying to create a sort of recall system where an admin sends a message to the entire user base via email after which all users have to confirm the message by navigating a link in the email (Confirmation token) and retyping the message in. The would a submit button on the page which will check if messages match then clears a confirmation flag in the database. I am stuck on where to even begin here. I am not worried about comparison logic in the controller. I am confused about how to generate the confirmation tokens, sending them, then redirecting users to a page for confirmation. At the moment I am use Devise with Active Admin but I am open any other gem suggestions. If any of you could give me a link to a similar tutorial or problem that would be great! Yes I have done research before asking but it most results had little relevance.
U could do this with devise
I'll share what was recently done by me, which is almost similar to your Q.
I did not use Confirmation link or any token.
Only Admin can create user.
On creation of a user, an email is sent along with id and password.
Upon user login for first time, redirect him to edit account for only password change.
Note: U can use friendly token for generating random password.
I've upgraded to Devise 3.2.1 and Rails 4.0, and I'm trying to figure out my signup now that one doesn't login on confirmation.
I allow users to create a message and specify the recipient of the message via an email address. Then I send emails notifying the recipient that they've received a message on the service. If the recipient doesn't have an account on the service, I create the account without a password, and the email I send to the recipient acts a confirmation email. With prior versions, the recipient would then click on the link, thus confirming, and then be taken to a password creation stage and then finally, they'd have a confirmed account created with password and can go see the message.
With Devise 3.1, they no longer allow login via confirmation as they consider it a security risk, however I fear it may greatly increase the complexity of my sign up process. I can no longer redirect to a password creation page as they aren't logged in. I'm toying with the idea of taking them to a special signup page or creating the account and then sending a special form of password reset.
I don't want to notify them via email, then send them a second email as a confirmation. That adds unnecessary complexity to my signup.
I wondered if anyone else has dealt with this issue and how they handled it. I'd like to avoid using:
config.allow_insecure_sign_in_after_confirmation = true
as that will go away soon and is really not the right way.
Is there a secure, yet fast way to do this with Devise 3.2?
Thanks!
I'm switching to using sorcery ( https://github.com/NoamB/sorcery ) for greater control over authentication and building my flow with that.
This is precisely the problem that devise invitable gem solves in a secure manner. I would recommend using this tool, rather than trying to hand-roll your own solution which is more likely to contain security flaws.
The gem workflow is basically:
An admin invites a new user.
The new user is created with a random password. (I actually helped write this bit!)
The user is sent an invitation email. (This is fully customisable in how it works, but has some simple default settings.)
The user receives a link, which contains a URL with a unique invitation_token.
After clicking this link, the user must choose their real password.
I am developing an application which uses Devise for user authentication. It performs all standard task that Devise handles (e.g.: Email verification during user sign up). But a user may have multiple email addresses to access his account and I want to verify all those addresses too.
My design is: user will get a email field in his profile page to add another email address to access his account along with his existing email address. After clicking submit, an email verification will occur like first time sign up process and user will be able to use both of this email address after successful verification.
Is there any gem available for this? If I need to implement it by myself, how can I do this without breaking the existing system?
It's very late to reply but recently I faced similar issue and found one gem which lets user have many emails, user can login with any email, set one email as primary, and provides support for confirmable, authenticable and validatable for each email.
Here is the link to gem:
https://github.com/allenwq/devise-multi_email
Hope it helps someone facing same situation :)
I am building an asp.net mvc web application.
Do I need to use captcha while user registration.
Because we make the user verify the email, by the standard way, like sending a link in the email and when the user clicks on the link, the email is verified.
Do you think bots can actually open an email and verify? And moreover the bots will need a new email address for every registration.
Yes, bots can create new email accounts and send and receive email from those accounts.
You don't need to use a CAPTCHA if your site is unlikely to be targetted by bots but if you are worried about an attack then a CAPTCHA is a good idea and fairly cheap to implement. You should bear in mind that it negatively affects the usability of your site and could make it difficult for some users to log in.
The "new email address" for every registration requirement isn't hard to beat (think mailinator.com) but I can't imagine a bot confirming your email, you just have to deal with sending out redundant emails and assess if that is an issue.
I think the jist of it can be summed up like this:
captchas help protect against
automated signups
email confirmation helps protect
against impersonation
Email confirmation is much easier than a good CAPTCHA for a bot to pass.