Tag Info

New answers tagged

0

A little late to the party - I recently read that the reason for this is that for many banks, the value of the increased security of allowing those characters is outweighed by the implementation cost and the support cost of dealing with customers that cannot remember their passwords. I'm not saying that its a good reason, but that is how I interpreted ...


0

Do not try to reinvent the wheel. Do not sacrifice security for usability The existing password resetting schemes are already tested and validated against access control threats. They are not perfect but they are accepted. The approach you propose to reset the password is very weak. Think about that I am an attacker. I do not need to go after the ...


0

A good password requires entropy. These special-character requirements happen because the site programmers were too lazy to do an entropy calculation and force a minimum amount of entropy. Instead, they pushed the work onto users, by forcing them to use one particular method of adding entropy (greater variety of characters). However, humans are actually ...


2

I would not recommend doing what you are trying to do. As you pointed out, the question/answer is much less secure than a normal user/pass, and security is only as effective as the weakest link, and obviously this sort of implementation is the weak link. Also, as an aside, it may be difficult to remember which security question was originally selected. Your ...


2

In this circumstance, it seems like the security answer effectively becomes an alternative password That's right. Which is also why this seems like a really bad idea. It will only work as a feature if the question is something simple, something the user will know without having to remember it, which means that an attacker can figure it out as well (by ...


1

While this is an interesting idea, I would suggest keeping it normal as you have it but give users option for 2 factor authentication in their account settings. In this when a user successfully enters their credentials, they would be emailed a link to click / follow. Once followed their session would be started. You have to assume your clients are stupid, ...


1

I think there is a serious flaw in your suggestion: unless I miss my mark, your "salt" isn't a salt at all: it's a challenge and, as such, it should be randomly generated each time a client attempts to authenticate. If this is the case, then you cannot use it as input for the pbkdf2 function. It will just not work. If it is not the case, then unless you're ...


0

They should be stored in plaintext, or base64 encoded. You can refer to how Tomcat is configured <!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --> <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" ...


0

The TCG spec doesn't impose any characters limit for the SRK and owner passwords as they are processed as hash values. Briefly, this means that for whatever password length, e.g. with TPM 1.2 it will always end up as 20Bytes/160bits (i.e. SHA1 hash). In reality, the command line tool or the GUI you're using might add some limitations, e.g. the GTK GUI ...


0

Yes, the account should be locked out. The reason is that the successful login could be from the real user, and the failed logins could be from an attacker. The fact that the real user has logged in should not reset the counter for the attacker. Of course you could track sessions and only lock out the user if they are on a different session than the real ...


0

And always remember there might be idiots who are trying to DOS someone they do not like by purposely trying to lock his account out using known email account.


2

There is no right or wrong answer. The more aggressive lockout policy is slightly more secure, and slightly less convenient for your users. You have to assess if it is worth doing based on your application's requirements, your knowledge of your user base, the value of the asset you are protecting, your threat model, etc. etc.


3

Computing entropy for a randomly chosen password can be broken down to a simple rule that can be used in virtually all cases, with some caveats. It's the log2() of the password character set space raised to the power of the password length. So, with a completely random password where all characters are independent, this is an easy calculation. E.G., For a ...



Top 50 recent answers are included