New answers tagged

3

Why does the administrator need to know the new password? 2) is actually only a problem if the administrator provides a new password, but not if the temporary password is randomly assigned and communicated to the user by a medium which the administrator can not eavesdrop. Don't let the administrator select the password, and he can no longer get any ...


2

Why you don't make an exception for 2? I mean, if the administrator sets a new password, it doesn't do the verification process of the old passwords. Just sets the new password and flags it so it needs to be changed at next logon. That way you can be sure the administrator has no access to the historical password file. There is a small risk for the ...


1

a business requirement [...] stipulates that a user is not allowed to reuse a previous password. The user cannot reuse her own previous password, but it doesn't prevent a user to reuse a password of somebody else, isn't it? I mean, if Jack and Mary are changing their passwords and Jack types the previous password of Mary, it shouldn't return a error, ...


0

Masking is useless with wss:// aka WebSockets over SSL/TLS. Since it is recommended to use SSL/TLS whenever possible, you can reasonable conclude that masking covers a marginal use case.


0

One of the ideas behind the OAuth system is that the resource provider can check the validity of your auth token and read its claims but NOT issue you a token itself. For that you need to go back to the auth provider and request one with either your username/password or your refresh token. if your resource providers automatically issue a new token when they ...


3

Many security "holes" are the result of programming mistakes. Programmers necessarily make assumptions about how their programs will be used and sometimes these assumptions are incorrect. A good example is Bobby Tables. At one time it was considered a common practice to accept input from a user, concatenate that with commands to a database, then execute ...


3

Here's a problem with your proposed approach. If you send the requests over HTTP, a 3rd-party can snoop the traffic and pick out the authorization token. Then they could send their own requests to the end-point using the token. Solution: use HTTPS rather than HTTP when doing the initial authorization to obtain the token, and whenever you use the token. ...


3

For the first question, your approach seems correct to me. You consume a token in the sendsms entry that can only be generated by the login endpoint. You could also use a generic token created by login, and not easily guessable (it would be equivalent to a cryptographically generated session ID), used as primary key to a database tuple. There you can store ...



Top 50 recent answers are included