I am looking at the nft auction example for hyperledger fabric. I see that when registering a user, the username and password is stored in the chaincode state.
On login, the user is retrieved from the chain and its password is checked against the supplied password.
But what if the user forgot his password. If user change the password, do we create another user in the chaincode since that current user record is immutable? But how to know which user record to retrieve during login?
Related
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.
How is it possible to pre-create users programmatically (via Graph-API) and have a same mail address configured for them to be used along with the password reset user flow?
I figured that the signInNames mail or StrongAuthenticationUserDetails mail attribute are being used with the standard flow. BUT, signInNames are unique and StrongAuthenticationUserDetails (Authentication contact info: Email) is not editable via Graph API as of now.
Any idea how to accomplish the scenario above without developing our own password reset flow?
I assume the scenario is creating user by invitation, where customer changes their password after first login.
Here is the sample for doing that
https://github.com/azure-ad-b2c/samples/tree/master/policies/invite
If you want to use the user flows,
You can create a user account as mentioned below, and then set the password reset user flow link to them. But then you will need to ask your customers to update profile as well, so that you know more about them.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet?tabs=applications#create-consumer-user-accounts
I'm building a web application for two different types of users, with a different registration form for each of them. I could split up those forms and send a verification e-mail after the form is validated.
But I'd prefer to have one general small form where the user enters his/her e-mail address and user type. The server then sends a verification e-mail with a link to further complete the profile, depending on the chosen user type.
Now my question is: should I include a password field in the small registration form? I have seen it before on many websites, but I can't see why I would include it. My plan is to make the user choose his/her password on profile completion. Nothing about the user will be stored until he/she completes the profile (I would securely hash the e-mail address with a timestamp in a url).
In general, the developers ask all the details including password at the time of registration and they allow to login using the same password. However, there is an open risk of unverified user can access all or some of the feature of the application. Sometimes the application also provides time frame of 24-72 hours to activate the user account, within this period user can access account with some restrictions.
For sensitive applications, you can ask for the password once the user verify the email address. So, that you are assured about the verified user.
If you are providing the feature to access the user accounts without being verified, make sure that the unverified account users can access the account with restrictions according to your application context.
Problem assumptions/conditions:
There exists a user with email foo#bar.com (unverified) in the system.
Visitor is not signed into the system (no current session, e.g. new browser).
Visitor signup/login using Google Account, through OAuth (user authorizes).
The system receives callback with uid and the email foo#bar.com [verified by Google].
I see three options here:
A. Sign in the visitor to the existing account with email foo#bar.com. This have some security implications.
B. Ask for a password [assuming there is a password in the system, this may not be the case with multiple OAuth providers] and sign them into existing account if it's valid.
C. Reject the login/signup, say email is already used, encourage user to login before connecting with Google.
What are the security risks with option #A?
What I've come up with myself:
'Anticipation attacks' could be performed, where an attacker anticipates a signup and creates an account on the system before the target does. After the target has signed up using OAuth he will have an active session on that account. Would be defeated by clearing all sessions on the account before doing #A.
When the user logged in through OAuth in Google, you can be sure that the email address you get back from Google really belongs to that user. So the thing you seem to worry about is that the user already known on your system by that email address does not own that email address. That should have been caught by the time he signed up, with an email conversation. But if it isn't, you might want to reset the password and send an email to the genuine user that you did so, and for what reasons. You may also want to log the user out if he is currently logged in. The user can still access his data, but only through his OAuth login session, or by responding to the email. The email should state that it is a precaution, as there is no way to find out if it really is the same person.
An "accidental attack" can happen too:
In step 1, the user who signed up with address foo#bar.com, in fact intended to type fuu#bar.com, but typed a typo: foo instead of fuu.
Now, the Google user signs up with Oauth and foo#bar.com, and in this way hijacks the account of the step-1 user. Accidentally :-) because of a typo made by the step-1 user.
So, either the step-1 user can anticipate-attack the Google user, or the Google user can accidentally-attack the step-1 user. (I cannot think of any other attacks at least not right now.)
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.