New answers tagged client-side
0
People speaking in absolutes about how this doesn't do a darn thing security-wise are missing part of the picture. Context menus are dynamically driven based on whatever you happen to be clicking on as well as the current state of the system. In most cases context menus are disabled because a good portion of the functionality provided within them is ...
0
It is probably more operational than security. If users have less options to change the environment (accidentally hide the taskbar, etc.) it could result in less support calls. If everything is in a known predictable arrangement on the system it also makes troubleshooting easier.
2
Nope. It makes absolutely zero improvement in security and disables a normally useful feature.
As you're probably well aware, there's a number of shortcuts that work to do all the things you've mentioned like F2 to rename files, Ctrl+C for copy, Ctrl+v for paste.
It does absolutely nothing to prevent keyloggers, screen cappers, viruses/malware etc. To ...
-1
This is mainly done as a "global" thing for IE not to take away the normal right click menu things like you get in the file menu in Explorer, but to stop the user from right click in the address bar and other areas and being able to change global IE settings (e.g., security settings).
5
The method you describe is indeed a classic algorithm for one-time passwords, but it has some drawbacks:
It is good only for N passwords, where N must be chosen at initialization time.
The client must invoke the hash function R times, where R is the number of remaining passwords in the chain, i.e. initially R = N. This limits the size of N, otherwise the ...
2
What you're describing sounds vaguely similar in it's aims to the one-time password scheme, HOTP.
However, after many thousands of logins, my login attempt under your scheme consumes more CPU time than the first login I attempted. With HOTP, the time to attempt login is constant.
It is also the case with this scheme that I cannot protect the secret on the ...
1
Firstly, the system is complicated and brings up other issues: Does the user have to remember how many times he logged in? If not, who does? Not his browser, he should be able to log in from anywhere.
Secondly, any form of client side encryption in HTTP connections is useless. A man in the middle can easily modify the javascript, remove the hashing ...
2
This is what I understand from your question.
You accept a password at the client side
You random pad the password.
You hash the password at the client.
You encrypt the hash using the public key of the server
You send the encrypted hash to the server
Server decrypts the hash using it's private key & compares it against it's stored hash to check the ...
6
Firstly, I'm assuming that you're doing this to weaken man in the middle attacks (which really are the only problem when it comes to plaintext passwords over insecure HTTP)
Client side hashing has little to no benefit. An attacker, on picking up the hash will not need to brute force the hash. All your server needs is the hash, so the attacker can simply ...
Top 50 recent answers are included
