A better reset password for group email - security

I've read through these 2 links about forgot password and what would be the better way to reset password based on several conditions and situations...
Forgot Password: what is the best method of implementing a forgot password function?
What is the best "forgot my password" method?
But I have a slightly different matter at hand.
We are thinking of having a reset password / forget password thing but the challenge is that we have users who belong to group email
e.g. engineering#mycorporate.com, h.resource#mycorporate.com, etc
Each group email has many users whose email are part of the group, and they need to use the group email to sign in to a local intranet system.
If we have a forget password link for them to reset password, I'm seeing a few possibilities here:
User keys in group email, verify group email, send a link with some unique string but temporary for 1 hour, click on unique link from email, put in new password and confirm new password.
User keys in group email, verify group email, send new randomly-generated password to group email, requires them to sign in within 1 hour and to change the password.
But somehow the issue still comes from the group email thing that any users belong to the group will know of the random password (point no.2)
But then, if using either method point no.1 or point no.2, Person Y carries out the forget and reset password, Person Z or any other won't know of the newly reset password...
What do you think?

It makes no sense to keep the password secret from the recipients of the group email, since each of them can initiate and complete the password reset process and set the password to whatever they like. If the account in question is not supposed to be accessible for all members of the email group, it should be changed to refer to a personal email address instead of a group one.
If you actually intend for all members of the email group to know the password, you will need to have some channel for distributing the new password to all members, regardless of the mechanism you implement for the actual change. Email is OK if you can count on public key crypto and make sure only the actual authorized recipients will be able to read the password, or if it is not a very critical system you can just ignore security best practices and just send the new password in plain-text email.

Related

Reset Azure ADB2C user password from central location

I have a unique requirement for a password reset.
We have users without email(or have invalid email), they just signup using a username.
So, to reset passwords, we want to have a separate UI application for support people that will allow resetting users' passwords without needing to send the password over email or can be sent to the common support email of the organization.
Is there a way we can use Graph API for this purpose? Custom policies need email to send passwords over(don't want the user's phone numbers at this moment).
Appreciate any leads in this matter.
Thanks.
Yes, you can.
But not ideal. The support person knows the password. And how does the user get informed of the password?
The correct way is to use a magic link that contains the username and when the user clicks on the link, they get the reset password flow. That way only the user knows the password.

"Sign in with LinkedIn" and existing user accounts

On our website, we have existing users who use username(=email address) and password to authenticate. Now we also want to offer "Sign in with LinkedIn" because we know that a huge fraction of our users is also on LinkedIn. Doing this is technically not too challenging with PHP.
For new registered users via "Sign in with LinkedIn", I would store their LinkedIn ID upon registration, so this is nothing they can manipulate. So when they return, it's an easy decision: Check the LinkedIn ID, if it is known than all is good.
Now comes the tricky question: If an existing user decides to use "Sign in with LinkedIn" for the first time, is it enough to check if we have his email address in our database and then assume that it is him/her? Should we check additional data or...?
Thanks for any hints!
Since email address is unique key and it represent the username, i think you don't need any additional data to check if it is him since his/her password is equivalent to the linkedIn email address.

Forgotten password reset page: should the user need to enter a username/email as well?

I am re-implementing the "reset password" functionality for the next version of my user management system. The way it works currently is:
The user enters their username and email address.
If this information is correct, a random token is generated and stored in the DB, and a link with the token is sent to the user's email address on file.
The user clicks the link, with the option to either "confirm" or "deny" the reset request.
If they confirm the reset request, they must enter their email address, as well as their new password (and repeat the new password as well). This is POSTed to the server along with the token. If the email address matches the token, and the reset request hasn't yet expired, the password is updated.
My question is: do we really need the user to re-enter their email address when they create the new password? If the random token is sufficiently strong, does requiring this extra piece of information provide any added security, or does it just worsen UX?
I don't see any value in doing this. Just make your key secure. Perhaps a 128-bit (that's 22 base 64 encoded characters) secure random. That seems large enough. Also add a timeout to the token life span. 24 hours seems a fine compromise between security and inconvenience.
I like the idea of adding the email address to the token so you can log failures more intelligently.

Authentication: Username (email) and password hashed together in one database field

I am currently developping a platform with a PHP framework for our client.
The head of the client's IT department wants us to handle authentication with one database field containing email+password+salt (hashed) so there isn't a plain text email field in this table and the password is more secure (his reasoning). The user should be able to login with his email address and password. So the email address serves as the username.
The idea behind this is that the email addresses of the users are very important for the business of our client and the IT head wants to obscure the email address in the login table in case of a possible attack. (e.g. a hacker gets access to the login table)
This is of course only possbile, because the hashed email adress for the login is linked to his email address in the profile table.
Basically there are two tables which are required for this process to work. The tables are in the same database of course.
One login table with the hash combination field (email, pw, salt) and one profile table which contains among other things the email in plaintext in one field. Let's call it profile_email.
I have strongly recommended not to use this solution, because I have never before heard of this and I have already identified some possible problems with this solution.
So my questions are: Is this a safe and feasible solution? Can you think of any unforeseeable problems? Have you heard of similar solutions?
from an entity-relationship-point-of-view ...
you have a login table that either contains a field that is a concatination of hashes or a hash of a concatination of string values ...
you have a profile table that conatins the usual profile info, including a sensitive info (email)
if those two are linked by a key, the simple hashing of that email address is useless, since the same info is available as a clear text string from the profile table
in the other case, when in the login table it is ONE hash of a concatination of email password and salt, it is no added security, since the link to the profile table reveals a part of the hashed concatination ... since you also have to store the salt, and since that also has to be linked to the login entity or be part of the login entity, an attacker knows all parts of the concatination except the password ...
i can't see why this approach is a good idea, except if you split the database login for authentication from the rest ...
let's say you have in your login table:
s=randomSalt
e=cryptoHash(email,static_system_wide_salt)
p=cryptoHash(password,s)
id=KeyForRelationToOtherEntities
now the database rights to this table are restricted, and only the authenticator_user may access it, but nothing from the rest of the database
the email address in the authentication process is hashed and hardened against rainbowtable attacks
the password too
you can index the e colum for searching during the login process
the authenticator can not access profile information or other information that can be linked to the login entity, since the access rights restrict the authenticator to the login table
the rest of the system can't access the login table for the same reason
one additional role has to be taken into account, regarding password changes and creating new users if the authenticator may only read the login table
... just my 2 cents here ... it's just an idea, and not really complete, or guaranteed to be secure ... just an idea that picks up the general idea of separating the login table
I'm not absolutely clear about your scenario, but i guess it's something like this:
valueToStore = hash(email) + delimiter + hash(password, salt) + delimiter + salt;
This would allow to search for the email, but only if the email is made case insensitive (e.g. lower case). Otherwise you could even get duplicates with the same e-mail address.
Because the hashed email is only part of this field, searching in the database is more difficult and slower. If the user changes his email address, you would have to update both fields, the password table and the profile_email table.
Because the email is available in another table anyway, it is incomprehensible why this should be more secure. If an attacker has read access to the database (e.g. SQL-injection), there is nothing to prevent him from query the other table too.
It would be more safe, if the email would be encrypted (not hashed) in the other table too. Then you can search for the email by hash and nevertheless encrypt the email with an IV.
In every case i would not store the hashed email and the password-hash into a single field. If hashed correctly then other parameters like cost factor and algorithm are also part of the password-hash, this is enough for a single field.

Should I send email activation link on password change (NOT a reset or forgotten password)?

I have searched all over and can't find any answers on this. It's clear that for a password reset scenario, where the user has forgotten a password, the system in question should send a temporary token/link to the user's registered email that takes the user to a secure page that allows the user to select a new password.
What I'm asking about is the case where a user knows the current password, and wants to change it. I'm proposing either
1) the user could enter the old password and new password, and an email will be sent off asking to click a link to confirm the change (which also serves to notify that a change request has been made), or
2) the user could enter the current password and gets sent an email with a link that takes them to a new password selection screen.
Yet, I don't see this process being used anywhere. Is there a reason this approach doesn't buy you any more security, or is there a security flaw in this approach?
It seems to me that this would add an extra layer of security, as it's a type of two-factor authentication. Consider the case where the user's password has been compromised, but the password is different from the user's email password, and the attacker has no other method of accessing the user's email. The attacker would not be able to lock the owner out, since the attacker would not be able to click the confirm password change link. As an added benefit, this would serve as a notification to the account owner that someone was trying to take the account over.
Is this simply deemed not worth the extra hassle?
I can think of 2 reasons.
1) It will annoy the user. Every extra step tries the users patience.
2) It doesn't add security. If someone has the current password, they already have access to the account. If the attacker doesn't have access to the email account, they can't permanently lock the user out anyway.
What you should require email verification for, is changing the user's email address.

Resources