194

First up, you should be more free with read-only access rights than read-write. It might be possible that a hacker has access to your data but isn't able to edit it. But, much more importantly, this is not about you. The fact that you might be screwed if someone has full access to your database is irrelevant. Much more important is your user's data. If you ...


78

A good server logs all requests sent to it, including URLs (often, without variable part after '?'), source IP, execution time... Do you really want this log (potentially read by a wide group of admins) to contain critically secure info as passwords? Base64 isn't a stopper against them.


72

What you are proposing is neither secure nor RESTful. @Netch has already mentioned the issue with logs, but there is also another issue in that you are showing passwords being sent by HTTP, making it trivial to capture passwords with any sort of wire sniffer or man-in-the-middle attack. When you do a GET request using REST, the different elements in the ...


64

If you get hacked you can restore the site from backups and fix it. But the hacker still has passwords for everyone's accounts! There are documented real world examples of this happening (Sony, Linked-in), where if the password tables had been properly hashed and salted, securing and restoring the sevice quickly would have been much easier. It's ...


60

The proposed scheme has issues in several areas. Security URL paths are frequently logged; putting unhashed passwords in the path is poor practice. HTTP Authentication/authorization information should appear in the Authorization header. Or potentially, for browser-based stuff, the Cookie header. REST Verbs such as resetpassword in your URL are ...


60

This is a really good example of insecure authentication, justified on the basis that if the site is compromised it is not possible to identify the person. If that's the case, why do we even need a username? just give each student a secret access code. Here are some of the flaws: Scale of breach - The entire site will become compromised by someone ...


42

If you care enough about rolling out the new hashing scheme to all users as quickly as possible (e.g. because the old one is really insecure), there is actually a way for instantaneous "migration" of every password. The idea is basically to hash the hash. Rather than waiting for users provide their existing password (p) upon next login, you immediately use ...


36

But I have other problems if someone gets in my database, i.e. deleting data. It's not about the problems you have, it's about the problems it might cause for all your other users. It's about removing temptation (or even worse, potential liability) for people working on the site to abuse data that's stored there. See, even though people should use ...


30

"Never store passwords in plain text" is not a rule. It is a best practice based on common security breaches on naive implementations of password protections. In that sense, the question: Is this scenario an exception to the rule of never storing passwords in plain text? really has no answer in the sense that no one is enforcing anything. All we can ...


28

When the user changes their password, require them to enter their previous password. You now have access to two plain text passwords, even though you are not storing plain text passwords in your database. Perform whatever verifications you want on these two passwords. This won't prevent the user from alternating between two passwords (with a suffix - you ...


25

I would suggest adding a new field, "hash_method", with perhaps a 1 to signify the old method and a 2 to signify the new method. Reasonably speaking, if you care about this sort of thing and your application is relatively long-lived (which it apparently already is), this is probably going to happen again as cryptography and information security is such an ...


23

In this case you could, upon registration, generate a hash of the entered password for every salt used so far, then check these salted and hashed passwords against all the passwords already stored. You could even cache all the salts used so far, this is potentially a smaller list than having to loop through all passwords every time to collect these. If ...


22

Store the hashes and verify an entered password against those stored hashes, the same way you verify a password when logging in. You would have to generate 'alternative' passwords from the one given based on numerical patterns to detect your 'minimal' changes. On login, you verify the entered password against a hash already, there is no need to store the ...


22

Users don't care. The only time they care is when somebody withdraws the money from their bank account and it appears that it has a link that a few days before, somebody gained full access to your database. In nearly every case I've seen such messages, they were misleading. The most hilarious one was on a website with "military-grade secure"-style labels on ...


21

Noticeable attacks like deleting data are usually the stuff of amateurs, and are the least of your worries. One of the first things an experienced attacker will do is attempt to gain legitimate access, so even if you patch the original vulnerability he used, he will still be able to get in. He will do everything possible to avoid drawing attention to ...


19

You should never be in a position to send a user their password. All passwords should be stored in a hashed format, with a sufficiently good hash function that recovering the original password is computationally infeasible. As for password resets, it depends on the application. If it's a web application, send a time-limited, use-once password reset link and ...


18

I have to post an answer here on a fallacy in the question itself. You are asking if passwords should be encrypted. No one encrypts passwords; no one, with the exception of services and programs like Firefox Sync and Roboform, whose sole purpose is to encrypt passwords. Let's take a look at the definitions: In cryptography, encryption is the process of ...


18

Rule number one of cryptography: don't roll your own crypto. You're taking a standard cryptography algorithm and you're messing with it. If the algorithm or combination of algorithms you're using hasn't been evaluated by security researchers for the past few years, you have no idea whether you've created a vulnerability or not. Stop right now. Using standard,...


15

One way to implement this is if you reset password, you are usually asked to enter your old password as well. You can simply just use regular string similarity comparison in that situation because you have both passwords in plaintext form at that point. Another way to implement this is to normalise the password, for example accented characters are ...


14

From Eric Raymond's design notes on Fetchmail: Password encryption in .fetchmailrc The reason there's no facility to store passwords encrypted in the .fetchmailrc file is because this doesn't actually add protection. Anyone who's acquired the 0600 permissions needed to read your .fetchmailrc file will be able to run fetchmail as you anyway -- ...


14

There is an important principle at stake here. There is only one person who has any business knowing a users password. That's the user. Not their wife/husband, their doctor or even their priest. It definitely does not include the programmer, database administrator or system technician responsible the the service they are using. That creates a challenge, ...


14

It's unsafe because it exposes your password a number of different ways. Any user can see it in the output of programs like top and ps aux -www. They don't need to be root to see your processes. It gets logged into your shell history, so if you do something foolish like chmod 777 ~, anybody and everybody can cat ~user/.history and view the password. If ...


13

Making the passwords accesible in plaintext in one way or another is already a HUGE security flaw. This is one of the most important security components on any site anywhere. I believe you already know that. My recommendation is to find another way to deal with those frauds. Exposing user passwords like that is just not worth it. You win a little and lose a ...


13

If you have Active Directory, you can test for membership in an Active Directory Group: public bool IsInADGroup(string ADGroupName) { bool result = false; List<string> myGroups = new List<string>(); using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, SystemInformation.UserDomainName)) { ...


13

No particular reason at all. It's as arbitrary as "your password may not be longer than 8 characters". It's programmers or product owners that don't know what they are doing. There can be some legacy reason for this, when the authentication system is linked to some credential system that has had certain limitations for historical reasons (something like a ...


12

The passwords are stored in plain text, unless a master password is used. When people tell that you must store only hashes of passwords, they are talking about server-side storage, not client-side. Server-side When you have your own website when the users can register/logon with their passwords, you don't need (and must never) store the passwords ...


12

Don't store passwords in the first place! Follow the example of Stack Exchange and let users log in with their identity on another site that provides authentication via OpenID. Implementations are freely available for most common web frameworks. Or possibly any other protocol. If it is in-house project for some institution (as your comment on the other ...


12

The simple answer is that a secure system does not know if they are similar. But some systems intentionally reduce the security for a specific password in someways to prevent new passwords from being old passwords, or similar to them. The cost benefit trade off is that a new password will be created prior to someone malevolently cracking the current ...


11

Tell him the first part. That you are storing the passwords in a hash. And that all password systems work this way. The administrator can change passwords, reset passwords, but can't read passwords. If your customer is knowledgeable about programming, they may know that you could intercept the passwords before the hash. Now move on to the second part. Does ...


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