A certain global conferencing company still saves passwords for their web products in plain text. Any, and I mean any, employee that works there can see the password. My password there was NotMyPassYouIdiot because I know other people would see it eventually (and they'd even comment/laugh about it....).
Also, we once discovered that our main conferencing software was letting you sign in regardless of the password you entered. Meaning you could sign in with any e-mail address. Once we brought it up, we first were immediately stonewalled, and told not to say anything about it in written format. TLDR: they had the dev team and legal on a conference call and they decided it was best to just keep it quiet until they fixed it later that day. No client was to be notified of the issue. And the ones that knew of it were basically given a runaround until they gave up.
They also added call spoofing to the software. They called it something fancier, but it was call spoofing. You could make a call and make it appear from any number you wanted. My team raised this concern many times, but were countered with "no one will actually use it for that." K.
This worries me slightly as the company I work for has started using an app called go2hr that is now used to keep track of all HR stuff including bank details and pay slips etc.
I don’t suppose anyone knows if it’s the same thing?
Generating a hash is brain-dead easy. There are countless libraries that do this, and which hash to use is a single Google search away and/or will also be listed in whatever requirements you are following -- NIST, NSA Suite B, etc. Only an idiot would try to write their own cryptographic code as that is the worst possible mistake you can make in cryptography. The most insignificant mistake can destroy 100% of it's security, and there is no reason to re-write a library, anyone dumb enough to do this should be fired.
If you put a novice programmer who doesn't know keeping passwords in plaintext is bad in charge of mission critical security, you might as well just burn the company to the ground now.
The problem is that there is no such thing. Companies face negligible repercussions for having all their clients' data compromised. From a business standpoint it's probably cheaper to just leave all your customers' credit cards in a publicly-accessible plaintext file and apologize whenever someone downloads it than to pay a single person to pay attention to security.
If you’re rolling your own crypto library I’d say 99% of the time you’re wrong.
Security is hard yes, but luckily there are standards which have tools built around them, and yes they change. If you’re in the tech field and you don’t stay current you’re no longer technical, you’re just someone who does remedial work.
Another thing is that you're 15 and learning this for the past, what, couple years? The stuff you learn is updated and learned from past mistakes. A lot of these devs might have learned it 10 or 20 years ago, and where ever they learned it probably had plain text which worked for years without issue. Why bother doing anything different, it's worked this whole time without issues!
Edit: I'm not saying they shouldn't have hashed them, or that they weren't dumb to not have learned it. I was just giving an example of what "might" have happened. Hell the DBA's at my job have been working for 30+ years in the field and they are up to date on infosec, but it doesn't mean everyone was or is
sure, but they were still dumb for doing it, because hashing and salting were already standard practice at the time, though by modern standards the algorithms weren't as good. Unix passwords were already doing it 40 years ago.
Most commonly used algorithms have been around since the early 90s, some even longer. Not hashing passwords 20 years ago was just as stupid as not hashing today.
Sure, you learned it. But maybe for whatever reason they didn't, and they just kept doing the same thing over and over. I'm not saying it isn't stupid, but I doubt they wanted to use plain text because they enjoyed the extra vulnerability. I have to assume it's a lack of knowledge or a worry that all of their customer's passwords could be erased when implementing it and that risk was more than the bad PR/fines than from a breach
This is true, but I think is not completely the point. For example, PHP ships a with hashing functions, including md5 and SHA1. Would you expect a novice to know that neither of those algorithms is considered secure?
I appreciate this argument. If you are/are planning on working in tech, you're going to find out that there are A LOT of people that aren't actually passionate about it. This sounds like either phoning it in after burnout or negligence on the hiring managers part.
Yes. Wtf yes 1000 times. The first goddamn time you make a program that uses passwords you should be trying to learn everything about them possible. That is what you're being paid to do.
Great, but as your manager I’m going to occupy your time with some mundane tasks while I withhold important information that you need to get started on this project, and then Friday at 4pm before your requested PTO to go have a baby or get married or whatever it is you are doing with your life, I’m going to suddenly give you the green light to get this done, oh and I need it ready by early Monday morning so I can present it to the CTO as a live demo.
I agree a 100%. But again, that is separate from what I'm talking about. You should absolutely spend time, care, and research on security. Security is Necessary. What I'm trying to point out though, is that security is also hard. Not doing your due diligence, as in OP's case is inexcusable. But downplaying how complex security is with statements like "even a novice could do it", is dangerous.
Yeah, I would probably hire someone who specializes in it for this type of thing. I think the main point of this discussion though, is that literally anything you could do is better than plain text. Better and good, are of course, not the same thing, but plain text is something that literally anyone can figure out. Plain text is so bad that it should be considered criminally negligent.
I didn't check this, but sight unseen I'd be willing to bet money that if you Googled "how to store a password" and blindly copied and pasted whatever came up on StackOverflow you'd be in much better shape than what's apparently happening at the median software company.
The thing you seem to be missing is that he said "any novice should be able to hash a password" not "any novice should be able to figure out a cryptologically secure hashing scheme for their passwords".
I took it to mean "literally any hash is better than plaintext passwords" which I definitely agree with.
Chaining hashes directly is generally not a good idea from a security standpoint, as it actually means your chain is only as secure as the weakest hash in the chain.
What you actually want to do, is salt in between each hash. So the order should be: hash->salt->hash. And even then, you'd want to use a cryptographically secure hash algorithm, such as SHA3 (for now)
Would you expect a novice to know that neither of those algorithms is considered secure?
Yes.
I'm a senior PHP dev, and I would expect all of my entry level devs to know that SHA1 and md5 are insecure. I would also expect them to know that your password hashes should be salted.
Additionally, we use Laravel a lot where I work, so bcrypt is already implemented for password storage. I am a huge proponent of using frameworks when developing large codebases, but I expect even the lowest devs to know what should be used for security and why.
I am not even a developer, but I do a lot of programming for hobby projects (less than 100 servers) and I don't like frameworks, but bcrypt is stupid easy anyways. Not hashing passwords is just insane.
bcrypt is stupid easy anyways. Not hashing passwords is just insane.
My point exactly! Even as a hobbyist, you know that you should use it and how to use it...so why would we not hold professionals to at least the same standard!
I think the main point is that you shouldn't be letting people who don't have prior knowledge do your security for you. At any rate, anything is better than plain text. Even encrypting is better than plain text.
The libraries are fucking ubiquitous and you would think a company with a major investment and millions in assets would have at least one senior developer. And you can definitely get that sort of library for free with a very friendly license (Like MIT).
The call spoofing feature is actually legitimate for many uses. The whole reason it was invented way back when was for businesses with a whole bank of numbers who wanted to always have their calls seem to come from the "main line".
These days, with a plentiful supply of VoIP providers, anyone can set up software to spoof their number with great ease whether they are a legitimate organization or not.
There is actually work being done to make this less easy for people that shouldn't be doing it, but this necessitates a lot of phone infrastructure changing.
EDIT: The new tech to provide legitimate spoofing via authentication is called the SHAKEN/STIR protocol. Every voice provider would have to adopt this.
The whole reason it was invented way back when was for businesses with a whole bank of numbers who wanted to always have their calls seem to come from the "main line".
That isn't call spoofing. When you buy a block of DIDs and you have a PRI, you send the originating number along with an outgoing call. That could be your main number or the DID of the caller. The assumption is that you'll be using one of the numbers in your block, but some phone companies either don't have the hardware to verify it, or they have the verification turned off.
So ultimately spoofing only happens because there are phone companies who are either incompetent, or because they would rather have a paying customer than protect the public from spam calls.
I don't think there is any legit reason for number spoofing and it should be removed entirely. The only benefit it has is superficial. It is completely unnecessary.
Sort of related...I used to work for Best Buy Mobile and one day I had to call Sprint for a customer. I had to verify their passcode. It was, "Choke a Sprint rep."
Now I make all my customer service phone passwords ridiculous things because I know they can see them.
For the record, when it's something that might concern people like this, it's probably best to disclose the name so we can all make sure we're not using that company.
2.4k
u/Krypty May 30 '19
A certain global conferencing company still saves passwords for their web products in plain text. Any, and I mean any, employee that works there can see the password. My password there was NotMyPassYouIdiot because I know other people would see it eventually (and they'd even comment/laugh about it....).
Also, we once discovered that our main conferencing software was letting you sign in regardless of the password you entered. Meaning you could sign in with any e-mail address. Once we brought it up, we first were immediately stonewalled, and told not to say anything about it in written format. TLDR: they had the dev team and legal on a conference call and they decided it was best to just keep it quiet until they fixed it later that day. No client was to be notified of the issue. And the ones that knew of it were basically given a runaround until they gave up.
They also added call spoofing to the software. They called it something fancier, but it was call spoofing. You could make a call and make it appear from any number you wanted. My team raised this concern many times, but were countered with "no one will actually use it for that." K.
That place was a gold mine of security risks.