Building an app for schools. Teachers will have classrooms assigned to them. Teachers login via email/password.
We also have district supervisors/administrators who need to easily distribute these classrooms to teachers. Currently I have a feature where they can assign a classroom to an email address, and when a user with that email signs up, it is automatically granted to them.
Is this safe? Or is it possible for two individuals to have the same email address?
Two email accounts cannot have the same email address, but whether multiple individuals are using the same address will depend on the policy of the owner of the domain, or it might be up to individual users for public systems such as Gmail or Hotmail if they want to share their address with others.
Is the app (or a particular deployment of it) restricted to only allow sign-ups from the domain of the school? (e.g. at Example College only alow emails that end in #example.edu?)
If so, you should check with the school as it is upto them how emails are distributed and used. If anyone can sign up you should be aware that people may share email addresses at certain institutions or that email addresses may be recycled for new teachers if no longer in use.
To make this approach more secure you should:
Verify the email address of each person that signs up. This can be a confirmation email containing a link with an ID generated by a cryptographically secure RNG. When the user clicks the link http://www.example.com/confirm.aspx?id=123456qwerty this will verify that they have access to the email address and grant them access to the classroom.
Expire the pre-granted rooms after a set number of days. This will reduce the chances of a classroom being granted to any recycled email address.
A couple things jump out to me.
1) You seem to be assigning resources to an account (an email address) before it has been created. How do you know that the person registering with that email address is the person that you expect?
2) You can only assume that an email address is unique if you control the domain of the email addresses and you enforce uniqueness. Otherwise it is possible that email addresses will be recycled over time (quite common with corporate email addresses like jsmith#company.com).
Related
I have a web app which I use to collect some information from a user (not name or email) and then plan on having them electronically sign a document via DocuSign immediately online (not via email).
In order to get a signing url (aka recipient view), it appears I have to provide a definition of a recipient. Part of the definition of a "recipient" is a username and email address. Is this true?
Does the DocuSign API/SDK require me to provide an end-user's (aka signer) name and email address? It seems like the API/SDK will always return a validation error if I don't provide these things. What if I don't have that information?
You need to provide the signer's name and their client_user_id within your app. You also need to supply an email for them.
The client_user_id must be unique per signer.
If you have the signer's email, use it.
If you don't, use a unique email address that includes the client_user_id to guarantee uniqueness. Eg noreply_{client_user_id} #your_company.com
Added
Re comments:
Yes, an email address is required by DocuSign to generate an embedded signing ceremony. But it is okay to fake one (that includes your app's client_user_id for the signer) if you don't, in fact, have the signer's email.
Re: Why is this the case? Because the email and name are used by DocuSign to index the "captive signer" (someone who signs your account's envelopes but doesn't have their own account with DocuSign). That's why a fake email must be unique to this person.
This technique of using name + email to identify people enables DocuSign to, for example, not require the signer to agree to the consumer agreement to use eSignatures on second and subsequent document signings with your account. -- This provides a better UX.
Since it is very common for web apps to know their user's email, this is usually not a problem. But if you don't know the signer's email, then everything works fine with a fake email as described above.
Added more
Re:
please provide a source for DocuSign being Okay with fake email address in this case? I mean is it legal?
Currently this technique for providing a fake email address for embedded signing (when a real email address is not available), is not documented on the DocuSign web site. I will add it to the embedded signing recipe when I revise it in 2017.
Re legality: the important issue is how your app authenticates the signer. Email is one way. Depending on the use case, email authentication may or may not provide a strong enough assurance to the relying party (the person who receives the signed document).
But we digress. Even if you do have a person's email address, it is common to authenticate the person beyond using their email. DocuSign has many different types of additional authentication built-in and easy to use including 2FA via SMS, pre-shared secret, in-person signing (which can include in-person verification of government ID), e-notary, digital certificates, telephone authentication, knowledge based authentication, and more. Most of these can be included with embedded signing if you wish.
Or your app (which is using embedded signing) can itself authenticate the person. When someone signed up for your app, did they have to first prove their identity? That was the authentication step. If no one else can log in as them, then they're still authenticated when you give them the embedded signing ceremony from DocuSign.
I have a DocuSign integration scenario that has resulted in what look to be multiple DS accounts created using the same email address but different passwords. I can login w\ the same email address, use two different passwords, and end up in two entirely different accounts.
Yes this is by design. The DocuSign platform uniquely identifies accounts based on user email and user name combinations. So creating multiple user accounts under the same email address is allowed.
One other thing to add here, there is also an option in DocuSign called
AnySigner
which allows you to send signature requests to AnySigner recipients which means all you send to is an email address (i.e. no username) and anyone who has access to that email account can sign and complete. This is a popular option for when you need something signed by anyone in a given department. For instance, you need a form signed by someone in your Human Resources department which has a common email they use.
I'm creating a forum, and currently trying to decide the most secure method for a user to change their EMail.
I figured it might be best to send a confirmation email to the old address, and once confirmed(after clicking the link in the EMail), their old EMail address will be replaced by their new address.
But I noticed some sites,
Requiring verification from the old email address is a definite boost to security, and should be required for critical sites like banking or high-profile social networking where a hijacked account can do serious damage, but it means users cannot change their email address if they lose access to their email account.
If you're creating a web-forum, then this probably isn't important enough to warrant an explicit release, and there are going to be many users that abandon a forum, let their email address expire, and then return. For this case I advocate simply sending a notification email to the old email address and including an "I didn't request this, please revert my email address immediately" link, that way in case of a hijacked account the original account-holder is still able to reclaim the account, while not inconveniencing those who genuinely no-longer have access to their old email accounts.
I'm working on a simple web service that allows users to sign up for free and upload a small amount of data. I can easily establish a quota for each user, but malicious users could create fake accounts to upload as much data as they like in a denial-of-service attack.
Obviously, there's no perfect defense against this type of attack, but what can we do to mitigate this problem?
Tie it to a more-or-less unique identifier (phone number, bank account number, facebook/google/etc account) or to a finite resource (such as time, by using a captcha).
use a captcha on account creation to ensure that it's a
human and not an automated process.
require a valid email address and require that they click a link in their email to validate that that's their email address and continue the registration process. This cuts down on their ability to create many throwaway accounts because you can limit them to only having one account per email address and they have to then create a new email address for each account they want to create.
When the user signs up, the user supplies a valid email. Most accounts are not enabled until a response has been received, usually by clicking a link in the body of that email. When that click-through is received, you should be able to grab an IP address. That should help you curtail an abundance of casual DOS attacks.
Consider Phone Number Verification
Requiring phone number for account creation is the best approach I've come across; Creating a new email or cycling an IP address is pretty trivial, but genuine sms phone numbers cost money to activate & grant your service the ability to restrict access by country-code.
An important caveat: Virtual phone numbers (like google-voice), temporary-phone number services, & burner phones can make sms-verification ineffective at preventing duplicate user accounts. Depending on your use case, it might be worthwhile to use a service, like Vonage's Number Insight api, that lets you identify those types of numbers.
Authillo is a passwordless authentication provider that prevents duplicate/fake accounts by leveraging sms verification, liveness detection, & facial recognition. Depending on how critical it is that you prevent fake accounts on your service, their base plan might be what you're looking for.
Just log the IPs and assume the same user if the IP does not change within a time interval. This is bad, because it would prevent multiple users in the same house (same IP) but it is a good start.
I setup my website to require unique email addresses (no two users can have the same email address), but I realized that this could allow someone to check if a person is registered on my website by attempting to signup with that email. Granted that this person would have to know the email address they wanted to try, but it could be useful information for some people (e.g. competitors who wanted to see if their users are registered on my website).
Is there any real way to stop this, or does this just have to be accepted as a possibility?
Edit: just to be clear, this is about creating an account. Even you provide a generic "invalid login" for bad logins, how would you require a unique email address or username without disclosing which usernames or email addresses are valid?
Additional, much later edit: One thing that wasn't considered here was maintaining the requirement for unique email addresses when you let users change their email address after account creation. Here, the solution I accepted of sending a "forgot password" email doesn't work nearly as well. Instead, it seems that the only options are to use captchas or limitations on the number of times an email address can be changed in a certain period of time to limit automated attempts.
If someone tries to sign up with an existing account — send a "Change your password" email instead of a "New account" email (and explain why).
Leave the HTTP response as a simple "A confirmation email has been sent to the address you specified. Follow the instructions in it to continue".
I suppose the issue is if someone forgets their password, you would ask them to enter their email address and you would send the password there if a match was found?
For that you can have users supply a question/answer challenge when they register their email address. Its a bigger pain for your users but if security is a concern then they may go for it.
Another possibility is your registration form. In this case users can enter an email address to see if its already "taken".
To address your concern you should just happily accept all registrations and send a confirmation email, even if they are already registered. That way the user doesn't know if they just registered the email address for the first time or not.
Finally, if an incorrect username/password is given, don't tell the user which is bad.
I don't think it's a terrible security risk unless membership to the site is sensitive, in which case you can use some of the patterns described.
Yes, that can happen and you cannot really do anything about it except limiting the number of checks/registration attempts in time. That will at least prevent automated checks by your competitor. Of course, if some guy decides to check if his girlfriend is registered there, then he will have that possibility.
Just a thought, not sure if it would work, but why not do something like the login page, where instead of saying "your password is wrong" it says "your username or password was wrong". Maybe just state "your email address is invalid". It's probably a bit of usability error, but if you are concerned about people doing as you say, then you might have to live with it.