Our Active Directory logins are currently e.g. john.smith#mycompany.com (i.e. the same as our email addresses). A friend said they used a number for login (e.g. 38292#mycompany.com) for security reasons. The login being internal and not public facing.
Wondering what others think/do and what is considered best practice. Thank you.
• Yes, as your friend said it is a good practice to keep your internal login ids and email ids as login ids different for several reasons. One of them is that if you have several people by the same names or similar spelling then it can be very hectic and weary to trace down a user’s activity across large span of internal environment presence. So, its best to keep internal application login different than email address as it helps your internal security team to continuously monitor and prevent threats like spamming a particular mailbox, sending phishing mails, etc. Also, it keeps your organization’s internal infrastructure at bay from attackers as brute force attacks through email ids are not at all possible since employee id numbers aren’t public.
• You can do so by configuring email address attribute for your users for which you can set the one containing employee number as their primary email address and other one configured, i.e., email address(firstname.lastname) as your employees’ alias email address or proxy addresses.
• Once, that is set, then you need to enable users to sign in with email address as alternate login ID. This feature tells the Azure AD login servers to not only check the sign-in identifier against UPN values, but also against ProxyAddresses values for the email address. This can be done through the ‘homerealmdiscoverypolicy’ resource as given in detail in the below link for your reference: -
https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-use-email-signin#enable-user-sign-in-with-an-email-address
Related
I'm considering building a website user authentication system using only one-time-passwords: users would get one in the email each time a normal password is normally used e.g. for signup, sign-in, risky actions and account deletion.
Some problems that I see with it that don't seem critical:
Can't change password to invalidate all existing sessions - can work around by storing sessions server-side and having a way to invalidate them for the user
Anyone can check if a certain email is registered in the system - doesn't seem like a critical problem for a generic website
Anyone can request an OTP for any email - will be dealt with using API limits per remote connection and a limit of 1 unused OTP per hour
I'm not seeing this method mentioned or used in the wild though. Does it have any major drawbacks? Many thanks!
OTP-by-email only is safer than password-only (it's basically like forcing the user to change their password every X hours).
I want to both address some of your non-critical points, and highlight some drawbacks.
Non-critical
Invalidating sessions
You don't have to store all sessions, only the invalidated ones, and only for the max duration of a session.
Checking that a user (email) is registered
That actually is a problem - it tells you that the email owner uses this website, which is a privacy issue, however minor.
But moreover, it's an attack vector. An attacker can scrape your user list, or just go attack that user on other sites, presuming that this email exists and links to a real human. Moreover, they can issue excessive OTP requests on their behalf, which I'll address in a bit.
All that said, there's no reason which this problem would manifest just because of OTP. A user can request OTP, and you can always reply with "If the email address hello#world.com is registered, a one-time password has been sent to it". This only has a slight usability implication.
Anyone can request OTP for any email
If an attacker can flood your site (from different IP addresses) with requests for OTP for hello#world.com, either you block this user (namely, that user has been DoS'ed), or you the site will flood the user's mailbox, which can get that mail server to flag the site as a spammer.
This could also be done in normal sites with password-reset emails, but that's why you typically want your user list to be secret.
Bigger drawbacks
Usability
OTP-only login assumes that the device from which you're logging in is also logged into the mail account linked to this site. Otherwise, the user has to log into the mail account in order to log into your site.
Single-factor authentication
The security community is pushing towards multi-factor authentication, where password is usually the first factor. A good practice would be to at least allow 2FA to users who choose to.
Account lockout
If a user's email account is no longer accessible for whatever reason (e.g. they used their work or university email), they can't log in, or even change their email address to their new one.
Email activity
If the site is heavily used, then it will be sending a lot of emails, to various public email services, continuously, all the time.
This alone may cause the site to be flagged it as a spammer, or even ratelimited.
If it does get ratelimited, some users will not be able to log in.
We are building a CRM type app although this would apply to any application where there are "members" and "staff" e.g. a shopping site, dating site, facebook etc.
In our app, users can change their password the usual way, by resetting it with email confirmation. Users can also have more than one email address associated with their account.
What we are trying to work out is how to prevent staff using the system taking over the accounts. We want staff to be able to edit the email address (because someone may phone in and request a change); the issue then is they can simply change the email to one they control - and request a password re-set as a user.
Are there any recommended best practices for this?
You could require the user to also authenticate the action by other means, such as when the email address is changed the user is sent a confirmation code via text message that they must input somewhere.
Another means would be to only allow access to the account if certain information is inputted correctly. This could be address information or DOB. It is unlikely that this information could be guessed from something like a name or account number.
1) Add one of those silly security questions like "What is your favorite color?" and store the answer, encrypted, in the database. Staff could edit the email to their heart's content, but if they didn't know the answer to the secret question the system wouldn't let them change the password. If you have concerns about staff trustworthiness, then you need to introduce something outside their control that serves as a final gateway before you can change the user account.
I imagine a simple implementation would simply check to see if the user reset their password. If so, on login, it challenges them with the security question to "authenticate" them before allowing them to proceed.
2) Logging, monitoring, and auditing. Record which staff accounts accessed the email address change form, what address(es) they changed, what they changed them too, and when they changed them. Also record the connection information of the people accessing the accounts. If your logs show one IP address accessing 4-5 completely disparate accounts, you might need to look into that. (Yes, I know you can use proxies etc. to mask this. Not perfect but it'd weed out the chaff pretty fast).
3) Hire trustworthy people! #2 should really only need to be used as a "check" against abuse instead of the end all be all to stop it.
For a website, I would like users to be able to log in using either their unique username or their email address.
However, this site will potentially allow multiple user accounts with the same email address. (For instance, they may be the same person working for two different companies, etc. Also, for business reasons, each user account is associated with only one company. So if users work for more than one company, they have one login for each one.)
Here are some possible ways to handle this when the user logs in with an email address:
If more than one account matches the email address, AND the password (hashed of course) matches at least one of the passwords for an account with this address, then do one of the following:
A. Tell the user that their email address is associated with more than one account, so they will need to log in using their username instead.
or
B. Same as A, however if the password matches exactly one of the account's passwords, just accept it and log in as that account.
I would like to go with B. However, using the password to differentiate between two accounts seems like it might have some obvious security pitfalls (that I may be overlooking), or even some non-obvious ones.
Would this be a good solution, or is there a widely accepted "best practice" for this?
The best practice for this is to have one account. Your database would contain records indicating which users have access/membership in which companies.
Most sites use the email address + single password as the primary identifier. People are used to it and it works. Go with that.
If people want other information associated with their login, such as other accounts, they can certainly share a login and then select which account to use after login. It's not part of the login, but it is associated with it.
Setting up multiple logins can lead to trouble as it requires more management, and it increases the likelihood of people being lazy about keeping their password secure. When you need to change your password, what then? Change them all? KISS = keep it simple, stupid.
You could allow single sign it to point to a "select your account" page on which the user decides which alias they wish to use for the current session.
If you go with "B", what happens if the user chooses the same password for both accounts? How will you choose which account to login to automatically and how will the user ever be able to login into the second account? Messy.
I've discovered recently LightOpenID wich i'm going to use as a login system for all my next websites.
As i'm fetching some infos when users register/login with LighOpenID, I'd like to know if it's technically ok to use user's email as unique id in my USERS table or if it's a bad idea ?
Thanks guys ,
FX
Thinks to consider:
It isn't mandatory to have an e-mail account linked to your OpenID account.
If there is an e-mail address, you are not guaranteed to get it back from the server, even if you ask.
Even if you get the address, you'd still need to validate it (e.g., by sending an e-mail message with a random token).
Users will probably own more than one OpenID identifiers (you are in such situation as soon as you open accounts at some major services like Google or Yahoo). Some of them will share the same e-mail address, some will not, and some will not even have an e-mail address set.
When the user changes his e-mail address behind the scenes, he'll lose his account at your site.
Using the e-mail as key does not really offer any advantage I can think of.
My advice is that, if you want to use OpenID, you should do it right. Read the OpenID URL from $openid->identity() after successful validation and use that to identify the user.
Additionally:
Keep in mind that URLs can be long; don't try to stuff it into a VARCHAR(100) column.
You might want to implement linked identities as Stack Overflow does.
It depends on your service. Normally, every email-adress is only assigned to one person. If multiple accounts per user are not wanted, it's ok.
Some families have a family-email-adress. But I guess they would also use the same account.
Why don't you take the OpenID as the unique ID? OpenIDs are unique and you get the OpenID before you get the Email-Adress, if you use only OpenID for logging in.
We are in the early design stages of a major rewrite of our product. Right now our customers are mostly businesses. We manage accounts. User names for an account are each on their own namespace but it means that we can't move assets between servers.
We want to move to a single namespace. But that brings the problem of unique user names.
So what's the best idea?
Email address (w/verification) ?
Unique alpha-numeric string ("johnsmith9234")?
Should we look at OpenID?
EMAIL ADDRESS
Rational
Users don't change emails very often
Removes the step of asking for username and email address, which you'll need anyway
Users don't often forget their email address (see number one)
Email will be unique unless the user already registered for the site, in which case forward them to a forgot your password screen
Almost everyone is using email as the primary login for access to a website, this means the rate of adoption shouldn't be affected by the fact that you're asking for an email address
Update
After registration, be sure to ask the user to create some kind of username, don't litter a public site with their email address! Also, another benefit of using an email address as a login: you won't need any other information (like password / password confirm), just send them a temp password through the mail, or forgo passwords altogether and send them a one-use URL to their email address every time they'd like to login (see: mugshot.org)
OpenID is very slick, and something you should seriously consider as it basically removes the requirement to save local usernames and passwords and worry about authentication.
A lot of sites nowadays are using both OpenID and their own, giving users the option.
If you do decide to roll your own, I'd recommend using the email address. Be careful, though, if you are creating something that groups users by an account (say, a company that has several users). In this case, the email address might be used more than once (if they do work for more than one company, for example), and you should allow that.
HTH!
I like OpenID, but I'd still go with the email address, unless your user community is very technically savvy. It's still much easier for most people to understand and remember.
If you use an email address for ID, don't require that it be verified. I learned the hard way about this when one day suddenly the number of signups at my site drastically decreased. It turns out that the entire range of IP addresses including my site's IP was blacklisted. It took a long time to resolve it. In other cases, I have seen Gmail marking very legitimate emails as spam, and that can cause trouble too.
It's good to verify the email address, but don't make it block signups.
Right now our customers are mostly businesses.
People seem to be missing that line. If it's for a business, requiring them to login via OpenID really isn't very practical. They'd either have to use an external OpenID provider, or their poor tech people would have to setup and configure a company OpenID.
If this were "should StackOverflow require OpenID for login" or "Should my blog-comment-system allow you to identify yourself via OpenID", my answer would be "absolutely!", but in this case, I don't think OpenID would be a good fit.
If most of your customers are mostly businesses then I think that using anything other than email creates problems for your customers. Most people are comfortable with email address login and since they are a business customer will likely want to use their work email rather than a personal account. OpenID creates a situation where there is a third party involved and many businesses don't like a third party involved.
I think that OpenID is definitely worth looking at. Besides giving you a framework in which to provide a unified id for customers, it can also provide large businesses with the ability to manage their own logins and provide a common login across all products that they use, including your own. This isn't that large of a benefit now when OpenId is still relatively rare, but as more products begin to use it, I suspect that the ability to use a common company OpenId login for each employee could become a good selling point.
Since you're mostly catering to businesses, I don't think that it's all that unreasonable to offer to host the OpenId accounts yourself. I just think that the extra flexibility will benefit your customers.
If you are looking at OpenID you should check out http://eaut.org/ and http://emailtoid.net. Basically you can accept email addresses for a login and behind the scenes translate them to OpenID without the user having to know anything. Its pretty slick stuff...
I personally would say Email w/ Verification, OpenId is a great idea but I find that finding a provider that your already with is a pain, I only had an openId for here cause just 2 days before beta I decided to start a blog on blogspot. But everyone on the internet has an email address, especially when dealing with businesses, people aren't very opt to using there personal blog or whatnot for a business login.
OpenID seems to be a very good alternative to writing your own user management/authentication piece. I'm seeing more and more sites using OpenID these days, so the barrier to entry for your users should be relatively low.