Tag Info

Hot answers tagged

26

What you've described isn't improving the security of the system. Its not a matter of opinion or emotion, security just doesn't work that way. In your example the hash(salt+password) is now your password. If it wasn't over https, then an attacker could just replay that value. Also you didn't really address owasp a9 aka "firesheep" style attacks.


25

First it is important to understand what kind of images the client does not show. In your case, as the message states, these are images which would have been "download" ed. That means these are not images which are embedded in the email (multipart, etc.), but referenced (HTML img, etc.). Now imagine what kind of information the sender could gain if your ...


16

You raise several issues. Server trust You never know what the server will do with your password once you send it Password reuse Password reuse can be prevented by you: don't use the same password at multiple places. Hashing If you were to hash the password before sending it to the server, then the hashed password would become the password. If the ...


15

It has to do with the general scope of what you are trying to protect. If you are developing a server-side application, you are trying to protect the server from both the user and his client system. Having the user's system (ie, the client) do your security work for you doesn't really help the server stay protected. There's usually an assumption that when ...


15

Hashing on the client side doesn't solve the main problem password hashing is intended to solve - what happens if an attacker gains access to the hashed passwords database. Since the (hashed) passwords sent by the clients are stored as-is in the database, such an attacker can impersonate all users by sending the server the hashed passwords from the database ...


13

You can't. A server fundamentally can't trust a client (there are some exceptions - if the client machine is hardened (hardware verifies firmware, firmware verifies OS, OS verifies every application running), it might be possible to do that (but not really - someone with a soldering iron could always modify the hardware verification), but if you don't 100% ...


13

Obfuscation might look as the first obvious step, but obfuscation has to protect something in the code and that something cannot be webservice functionality because that is reverse engineered by intercepting the traffic even if it is SSL encrypted. Certificate pinning can prevent simple SSL interception by trusting a predefined certificate. You can ...


12

The core reason is not hate... it's insecurity. A general principle is to trust nothing you don't have control of. In the case of a user authenticating to an application, unless you provided the laptop to the user, configured its controls, and those of the environment it sits in, you can't trust it. The traditional way to look at it is that if an attacker ...


12

If your "paranoid dial" is turned up all the way to 11, the short answer is "No". No matter how you store your passwords, there will at some point be a transfer in memory that is a cleartext representation of some authenticator. That "cleartext" may be your ASCII password, or it may be a hash of it, but it will still be enough to independently validate ...


11

One reason for this is automatic image loading can be used to track users opening the mail (in the same way as a read receipt). Say a marketing company sends out a mail to a thousand users and for each user they place a link to a different image in the mail (so user one gets image0001.jpg, user two gets image0002.jpg and so on), and host the images on their ...


11

There will never be a single perfect checklist, but here's a few things worth going through: Wikipedia doesn't do half bad on this one More for AJAX or other rich interfaces, but worth a read depending on your architecture - OWASP This seems worth a test drive - haven't tried it myself - Javascript sandbox Yes, none of these is a true "checklist" - IMO ...


11

To do 10 checks on the server side is likely not going to put any real stress on your server. Unless you are at the point of thousands of request per second, you will be okay. At that point, you would probably implement clustering, etc. Security is always worth the extra cycles. Client side validation is never sufficient. When you think about validation, you ...


9

First off, you need to realize that you're asking for anonymity and confidentiality. Those don't always go together, and if you don't keep both goals in mind, you will wind up with confidentiality (which is what SSH, SSL, and OpenVPN are more designed for) but miss out on anonymity. Second, you really need to read some documentation on whatever solution is ...


9

Greetings, there are plenty of password managers out there that will do what you need. A popular option is KeePass , which is free and also has the advantage of having apps for a few platforms out there (Windows phone, IOS, Android).


9

Fundamentally you cannot secure your client. At best you can obscure and obfuscate in order to make it more difficult for an attacker to modify the client. You mention that it is not a security issue because the server is properly secured, but merely an annoyance. It may be more annoying to try to obscure your client than to let a few modified clients make ...


8

When someone sends you an e-mail, they know very little about you personally - especially if you use a public e-mail service. The sender can include links and/or images which reference other servers on the internet. If your client automatically downloaded one of these images, that is synonymous with you automatically clicking on a link without reading it. ...


8

I'm not sure if people "hate" the mechanisms you describe on the client side. I think this has more to do with legacy practices and uneven support on the client. Firstly, you need JavaScript for implementing this, if you want to do it via form-based authentication. HTTP Digest provides something similar natively, and is supported by most browsers ...


8

The obvious usage is client authentication. It can be used to improve security in combination with a passphrase or smartcard, or to be a convenient replacement for entering a password. The WebID single sign on protocol is an interesting proposal in this context. The main issue with client certificates is that it is bound to the browser. So if you are on ...


8

This sounds a bit stretched, maybe counter-productive, sub-optimal and it doesn't really offer much added security. The "password" is actually seen in plaintext, because the password is the string you finally send in the place of the real password. What exactly are you trying to achieve? In any way, if you are really trying to have the 'real' password 'not ...


8

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 ...


7

If you're calculating the hash on the client side, you add the risk that an attacker only needs a hash of a user's password to log in instead of the actual password. You could probably get around that by sending a nonce to hash the password with (basically a per-session salt), but then you'd still have to hash that on the server side too, so why bother doing ...


7

Unless the service provider lets you see the database, no, there is no way to guarantee it. This has proven to be a risk in the past and no doubt will again. You can't do much in this scenario before the server to pre-hash your password, as that basically makes your pre-hashed password the target that your password would be in an environment where ...


7

There are few time when client-side hashing is worthwhile. One such circumstance is when the hash process is computationally intensive, which can be the case with PBKDF2. Addressing your concerns: Also avoid unvalidated suggestions about cryptography you find on the internet. (Disclaimer: I am not Bruce Schneier.) Deterministic salts aren't a problem--the ...


7

The extra protection added by the client-side hash is extremely marginal. From the point of view of the server, the hash result is the password, because the server grants access to whoever is able to show that hash value, without requiring the actual password. In particular, if a "weird bug" results in making the hash value apparent to the attacker, then you ...


7

None. If they don't decompile your app, they will just put it through a proxy with it's own SSL certificate. Your client can't provide security for your backend.


6

For your specific example there is at least one business reason and one security reason that it might not be done that way. Business reason User requires Javascript. This is not necessarily always enabled. Security reason Passwords are normally stored hashed with a salt. You would need either a constant salt, which would make it less useful; share the ...


6

The article points out that the system leaks information: other people's passwords. Every time it rejects your password, you know that someone on the system has that password!!! Maybe you can approach it from the standpoint of how expensive it would be impose such a situation since you only store salted hashes (or whatever) and not their actual password? ...


6

In order to sign client certificates, you will need a CA certificate you control. Paying for one is out of the question in most cases, as global-trusted CA certificates are a security hazard for the rest of the Internet. So in these cases you have to make your own CA and create your own server and client certificates. So let's start with a basic ...



Only top voted, non community-wiki answers of a minimum length are eligible