We are using the API with Send on Behalf functionality in our system would like to check on the impact of the expiry of the SOBO’s user password on the API.
What will happen during the API calls when the password for the SOBO user has expired.
Alternatively, can we exclude those accounts from the password expiration policy?
If not, how should we go about ensuring that the password expiry does not result in failure of the API calls.
Password expiry is only enforced on logging into the WebApp. The general best practice is to have your API (or SOBO) user never use the DocuSign Web Application.
So, even if the account has a 30 day user password expiry it will not be enforced via the API and the password itself will only expire on a login attempt via https://account.docusign.com/#/web/login.
Related
Is there a way to increase the expiration time of OTP codes delivered via email during MFA and password reset? My users are getting the email later than 8 minutes and by the time they use the code, it is expired. What is the actual default? Is there a way to leverage the OTP technical profile described here Define a OTP technical profile in an Azure AD B2C custom policy ?
I believe the default expiration time is dependent on the method you're using to send them to code.
As far as I can tell from the documentation, the most customizable method for sending the OTP is using the OTP protocol provider you linked in your question.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/one-time-password-technical-profile
This protocol provider has a specific metadata item you can set for the expiration time (CodeExpirationInSeconds). It's min is 60, it's max is 1200 and it's default is 600.
If you need more fine grained control over the expiration time of the code, I would use this protocol provider to do it.
I am using Microsoft Azure authentication for user Login ,
After login of user there is change password section in my application where user provide his current password and new password so my query is
Is there is any Api(Graph) to GET Current Password for that user OR Any API(Graph) through which we authenticate current Password which provided by user
Is there any other scenario which help me to authenticate current password which was given by user while changing password
Or any other way to get current password for that user
thanks
There is no way to get the current password for users.
It would be a massive security vulnerability and imply they store them insecurely.
There is a way to authenticate a user like that, but it won't work if the user has e.g. MFA.
I would suggest a different approach.
Check how old the authentication is (id token has the time it was issued).
If it is older than, say, 15 minutes, require the user to authenticate with AAD (prompt=login).
You can also require MFA for the login if you know all your users use it.
Then they should be able to give a new password, which you can then set with Graph API.
So instead of making a call to check the current password, require a fresh ID token and rely on AAD to check the user credentials.
Also, the users should be able to change it themselves already as written in docs: https://learn.microsoft.com/en-us/azure/active-directory/user-help/active-directory-passwords-update-your-own-password
I have a chrome extension which allows users to exclusively login with google and no other provider.
In my (node + couchdb) backend I need to construct a user account from the auth Response provided by google's oauth2 api. I was thinking about using a hash of the id_token as a password after verifying the token using the tokeninfo api
I realize that the id_token changes from time to time. In that case I was hoping to update the user's password automatically.
Here is the flow I had in mind:
1) User signs in on the front-end and gets an id_token from google
2) Id token is sent to the server and verified using the tokeninfo api
3) If verified, a user account is created with a password being the hash of the id_token.
Do you see any security holes with this flow? If so, what are the alternatives?
It is probably annoying to change user passwords all the time, and this ties your authentication too much to google. What if you want to implement password logins in the future, etc.
I would recommend to use something like proxy authentication instead.
http://docs.couchdb.org/en/latest/api/server/authn.html#api-auth-proxy
make sure to set
[couch_httpd_auth]
proxy_use_secret = true
in the config.
On a side note: if you sync the couchdb password with external secrets like in the question, you should sign the password with a hashed secret that you control completely.
This is a question about generating a token for a user to reset his/her password, without storing said token in the database. This token would be part of a "reset password" URL sent by e-mail.
An answer posted by sudo explains that you can send the user a token with the following information
name
expiration date
hash(secret + user name + expiration date)
The problem with this method is that the user could change his password several times before the token expires. I think this is quite bad because it means that if the user accesses the URL from a shared computer that retains history, anyone could reset our user's password (even if just for a limited amount of time).
So my question is: is it possible to have a token that is usable only once, and that is not stored in the database?
Yes. An easy approach to getting a one-time use token you don't have to store or manage is to offload user management to a microservice like Stormpath where it takes care of all the user management for you-- password reset, password storage, user profiles, authentication, etc.
For password reset here's what it would look like:
User initiates password reset work on a web page
You make API call to stormpath with user's email address or username
Stormpath sends out reset email to user (your "from" address, custom HTML, etc) with a link + token. The reset token that is unique, one-time use, and expires if not used within 24 hours
User clicks on the link and lands on the reset page
You pull the token from the URL and check Stormpath for token verification
User submits new password
Stormpath sends out reset success message (your "from" address, custom HTML, etc)
You can build your own UIs in this flow or use an out of the box, customizale id site (id.mydomain.com) that Stormpath includes.
User never knows Stormpath exists and you don't have to manage or store any passwords or reset tokens.
Full Disclosure - I work at Stormpath
A possible solution is to use a slightly different token:
user name
expiration date
hash(secret + user name + password_hash + expiration date)
When the user accesses the password reset page for the first time, you can retrieve his password hash from the database, and check the hash. It matches, the user can reset his password.
When the user accesses the password reset page for the second time with the same link, it won't work: password_hash has changed, therefore the hash won't match.
But.... There is a problem if the user actually types his original password. In that case password_hash will stay unchanged and the token will remain valid. Because of this edge case, this solution isn't really viable.
I am trying to determine the best way to enforce password expiration rules in my solution.
The server-side exposes a REST API for operations with a custom active Security Token Service (of sorts). Client applications pass user credentials to a REST endpoint where the user is authenticated on the server. The response includes a custom security token representing the user which is then passed to other API methods so the call can be authorized. The server is stateless and does not maintain any reference to the identity or claims information (i.e. session-less).
We have password expiration rules that are enforced by the server. So, when authenticating a user, it is possible that their password has expired. I need to communicate this to the client so they can do whatever is needed to have the user change their password. (There is another REST endpoint for changing the password on the server.)
Questions
It seems to me that authenticating a user with an expired password should fail. However, I need to know the identity of the user changing the password when making the second API call, so should I go ahead and return a token even when the password has expired?
How should I inform the client that a password change is required? I thought about including this as a claim in the token, but that would require me to reissue a new token after the password has been changed or modify the original token which isn't allowed. My other thought was a custom HTTP Status Code that I would correspond to meaning Password Change Required.
The answer to this question probably depends on the previous two, but I don't want to authorize a user that has an expired password if the token is passed to any other APIs (besides changing the password). What's the best way to handle this?
So, what I ended up doing (certainly not the be-all-end-all solution) is having my Authenticate endpoint return an AuthenticationResultCode enumerated value in the response in lieu of a simple pass/fail boolean. Possible values for the enumeration include:
ValidCredentials - the user was authenticated and the AuthenticationToken is included in the response.
InvalidCredentials - the user was not authenticated
CredentialsExpired - the user was authenticated but their password has expired. I have yet to determine if the AuthToken will be included with this result.
NoCredentials - no credentials were provided to the request
Now the client has more information about the result than a pass/fail value (which I really never checked anyway) and I can take the appropriate action in response such as automatically displaying the ChangePasswordDialog when CredentialsExpired is received.
Like I said, still working out whether or not I should still send the token when the credentials are expired because I don't want to be able to authorize a user if their credentials are expired but they've already been authenticated once and I don't think it makes sense to re-authenticate after changing the password (after all, I have to be authenticated so I can change the password in the first place). Maybe just a simple IsLocked or IsExpired property on the client will suffice...