259

Yes encrypt, it is easy. Plus according to a 2014 Software Engineering Institute study 1 in 4 hacks was from someone inside the company with an average damage 50% higher than an external threat actor. Link to source: https://insights.sei.cmu.edu/insider-threat/2017/01/2016-us-state-of-cybercrime-highlights.html Although this is the 2017 version.


142

The way I see it, not storing passwords in Git (or other version control) is a convention. I suppose one could decide not to enforce it with various results, but here's why this is generally frowned upon: Git makes it painful to remove passwords from source code history, which might give people a false idea that the password was already removed in the ...


113

Many people have looked at the reasons not to allow name changes from both a security and a community standpoint. However, there are plenty of legitimate reasons to allow username changes, even if the username is separate from the display name, for example: Someone has changed their real life name or the name by which they'd prefer to be called, due to ...


110

What are the real world chances that someone would steal his identity? Running a MITM attack on an HTTP connection when on the same LAN is basically trivial. ARP is not designed to be secure. Some high end switches provide reasonable mitigation, but it is mostly pretty weak on anything that is not fabulously expensive. There is an employee complaining ...


93

First, the non-security reason: Password Change Workflow Passwords change independently of a software application code. If a DBA changes a database password, does it make sense for developers to have to update the code, get a new build and release to production, and try to time it all? Passwords are a runtime configuration artifact, not development ...


81

My advice would be to remove the secrets from the drop-box and store them elsewhere. Your instructions have to be easily human readable by anyone, but they can include instructions on how to get access to the properly secured part of the data. That lets you separate the accessibility side of things from the security side. Once you can think about security ...


80

What I see most commonly is allowing the authentication and signing the user in, but locking meaningful features away until the email is verified. You should bubble up an error reminding the user to re-send an activation email if they try to access one of the restricted features. It is poor design to ever lie to a user - if they submit the correct username ...


74

Get a USB device. Put all secrets on the USB, preferably in a KeePass file. In the documentation, tell the new person where the USB is and how to unlock it, but put the device in a secure physical location like the owner's office, the company safe, a secure deposit box, etc. Somewhere out of the reach of the public, and away from the prying eyes of other ...


43

This seems like a solution geared toward backend session management. I'm speculating anonymous users don't initiate any sort of session, but a session gets instantiated once you hit the login page. When you log in, it gets noted in your session and you get to use their site and services. If you don't log in within a certain time, they go ahead and ...


40

Yes, you have to encrypt your connections. Let's take a scenario where you believe your network is physically secured (with required physical security and other required security measure) and no internet access (since you have indicated you only allow VPN access to trusted sources), but let's assume your employees take their laptop home and connecting to ...


35

I would say as long as they are not able to change their unique identifier. I.e. they can change the name they show up as, but that name is tied back to an unchanging user ID number (this will make your DBAs happier too). I'd also make sure user's couldn't change their name to an old name of another user (to help mitigate the scam potential Anders is talking ...


30

Never hardcode passwords or crypto keys in your program. The general rule of thumb is: the only credentials you should store on a user's machine are credentials associated with that user, e.g., credentials that enable that user to log into his/her account. You should not store your developer credentials on the user's machine. That's not safe. You have to ...


29

Create 'emergency use only' accounts For most systems, you will have some kind of privileged accounts that are used in their everyday administration, those may or may not be personalized depending on your organization policy. As for any credentials, you may lose access to them for various reasons - either by the person knowing them getting hit by a bus, or ...


29

Risk of Repudiation In addition to all the fine answers about employees as a threat and visitors as a threat, I think you have to consider that the mere fact that the traffic is unencrypted is of itself a vulnerability even in the total absence of hackers. You are setting yourself up for a situation where any employee who does something they are not ...


25

I can see where you're coming from, but the answer is basically "that's not what the salt is for". If I'm trying to discover a particular user's password, the salt doesn't help much if it's right beside the hash. However, it's not expected to be useful in that situation - cracking an individual user's password is difficult enough already. The point of the ...


25

It's always important to keep in mind that suggestions do have to be tailored to fit your use-case. Security safeguards taken by, say, the NSA to protect all the zero-days they keep around for a rainy day should be much more stringent than security safeguards taken to protect up-votes on a cat-picture-posting site. On one extreme, I can think of an example ...


20

What's the point of stealing hashed passwords? Let's say I steal a hashed password, I can take a random string, hash it, and see if the hashes match. If they do then I've just cracked your password. For example, assume that under some hash function we get the following hash table: "cat" --> AA "dog" --> AB "elephant" -->...


18

Even though the entropy in a large random token suggests that the token would be a secure mechanism of authentication, there are many problems associated with it: The token is fixed per user, so a user can't change the token if they suspect it is compromised. The token could be used unlimited times, which increases the opportunity for compromise. Based on ...


16

Yes, it's normal for a pen tester to ask for credentials (but not so much an ISP). The application as a whole can't really be tested without access to credentials. Someone without credentials should only be able to interact with one interface - the login screen. Given test credentials, however, every form, every upload, every data entry point in the ...


16

It could be that they are have issued a verification token of sorts to the form that they postback to the server as part of the login, which times out after a period of time. Not saying whether its a good solution or not, just that it may be the reason. OWASP have this information: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#...


15

This is almost equivalent to passing the password as a GET parameter, which is bad. It's discussed here: Is there a difference between GET and POST for web application security? Also, in your example URL you are not using HTTPS. Sending your password in plaintext over the network is also bad for obvious reasons. Next, can a user change their token in the ...


14

Some companies, especially larger ones that have been around long enough to develop bad habits, have roughly the following fallacious security model: The network is safe as long as nobody else plugs into it and nobody inside is technologically skilled enough to abuse it. Is this possible to protect in all cases? No, but proper physical/building access ...


14

In 2018, the answer depends on your threat and risk analysis results. Which, of course, you have performed, identified the likely scenarios, rated them and made a business decision based on the impact and frequency, according to a proper statistical or quantitative method. Your individual employee, however, has made his own personal risk analysis and ...


13

Keeping secrets (passwords, certificates, keys) separate from source code makes it possible to manage source and secrets according to different policies. Like, all engineers can read the source code, only the people who are directly responsible for production servers can access the secrets. This makes life easier for developers because they're not bound by ...


12

This convention, like many other security "best practices" is a handy way of making sure that things don't go wrong because of bad habits or routine. If you always remember that your sensitive passwords are in your version control system and if you never give anyone who shouldn't have the password access to the repository and if your repository is stored as ...


11

Maybe a better solution to your situation is to design the system such that even if you are hit by a bus, and your credentials are lost forever, nothing bad happens. Perhaps it's best to think of the problem as two problems, authentication and authorization. Authentication establishes that you are who you claim to be. Some system can know that a request it ...


8

While, as @gowenfawr has answered, it is normal for a professional pentester to ask for user-password you should ask them the following questions: What tests are you going to perform with these users? (so you know exactly what they are doing). How are you going to manage the credentials I give you? (so you can know if they are going to protect the ...


8

The login credentials were found in password dumps from other sites. They were credentials where the username was a .gov email address. The concern is that people tend to reuse passwords and the passwords used on these sites are the password for their government login credentials. Either the passwords were stored in plaintext or the hashed passwords were ...


8

As mentioned, allowing users to easily change usernames (let's call it "display name" to disambiguate) makes it easier for users to dodge the consequences of harassing or scamming other users. If your site has a social aspect, maybe consider whether bans, blocks, reports, chat histories, etc will carry through a username switch (ie will a user be aware that ...


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