What are the worst security practices you've ever witnessed?

twitter logo github logo ・1 min read

Got any similarly tales?

twitter logo DISCUSS (167)
markdown guide
 

Two things that drive me absolutely nuts.

  1. Not encrypting your hard drive especially on a work laptop. For those who have a Mac and are interested in learning more here is a great post.
  2. Leaving a work laptop that has access to production information and data open, unlocked, and unattended. DONT DO IT EVER!!!! I have actually thought about leaving people notes when I see this, "If I was a hacker you would have been screwed, lock your laptop next time"
 

Where I work we have a donut rule. If someone is able to gain access to your workstation and send an email to the rest of the company mentioning donuts, you then have to bring donuts for everyone.. Its extremely effective

 

At my company we do pizza instead. That is more cost unfriendly, but they do get they point.

 

We do same, except that we bring cakes πŸ‘

 
 

Why does no one seem to take securing work laptops seriously?

In a previous job, we had laptops with no way of securing them to our desks. We had to lock them in our file cabinets at the end of each day.

 

I work for a cybersecurity company, we help Fortune 500 companies track down and patch the worst vulnerabilities in their infrastructure. However, I believe that no matter how robust you make your infrastructure the weakest link will always be the human component.

this

Right! Common sense and educating the humans that work at or with a company can go a long way.

Not only that, but also removing the human component, where possible. People will always error, so removing the possibility to error is just as important.

 

My favorite is when I bring this to the attention of my co-workers and they say "Yeah, but I know you're supposed to be here"

1) We definitely don't know all the people in our org (and people constantly walk up to desks to drop off papers/notes regardless)

2) What if I was having a particularly salty day and felt like burning bridges?

 

I feel this!!!

Most of the devs are pretty good about it bc we will all mess with each other's laptops if they are left open. Nothing malicious but change some vim shortcuts, maybe a new screen saver or background. Great way to promote locking your computer πŸ˜‚

I've done the wallpaper one to the others in my department (one of them still hasn't removed the weird picture of them from their wallpaper rotation).

It's really hard to take security seriously when I asked a higher up IT person why we promote IE as the default browser and their answer was "For security reasons" (this person has since moved to another company, but we still default everyone to IE as the browser)

Ohh, right. I work from home, but once I went to get a cup of coffee and my husband put on an update emulator on my MacBook. I just assumed the update started on its own while I was gone and actually waited around for about 30 minutes until I figured out just what was so funny.
The update emulator (a website on full screen, it’s even animated) is a good, safe prank. Bonus points if they had open files unsaved. I suppose it also exists for other operating systems.

Holy wow this is amazing 😍

For anyone curious, Fakeupdate.net seems to be a good source for this πŸ˜‰

I guess that was it. I was so angry at myself for falling for it that I just closed the tab in a split second without checking the name πŸ˜‚

I'm realizing this could also be repurposed to get out of things πŸ€”

I'm a fan of extensions/user scripts in the browser to give someone a special experience. Like making CSS grayscale filtered, etc.

At my last job we were also huge fans of the extension that replaces all images with Nick Cage and the one that would randomly play the John Cena intro every 1/1000 tabs.

VSCode has a beautiful theme for this situation. Hot Dog Stand.

The Hot Dog Stand theme actually is an ancient prank. Windows 3.1 (!!!!!) had this somewhere hidden deep, deep down in it's OS.

I used to change the language of my friends' mobiles to Japanese. It was easy and fun at Nokia 3310 era.

 

This is especially true if one feels he is gonna be fired soon. Or worse, already fired but had to spent some time to hand off some work.

 

If you're a Mac user, this is where you want to go to make sure your data is encrypted automatically (described in more details in the link Molly posted)

 

And if you want to go a step further and create an encrypted password protected folder (drive) on macOS check out this post πŸ˜‰

 
 

In our company we change settings like background image, color theme or screen rotation. It is fun to see your colleague to try changing it back when everything is up side down ;-) Oh, and he knows what he did wrong

 

we are encouraged to open slack on unattended computers and promise all in company free beer.

 

We called this hotdogging. Anyone who left their computer unlocked we would send an email from their account talking about their love for hotdogs.

 

A global phone service provider once had themselves called out on twitter for storing passwords in plaintext, one of their support reps replied with "What if we don't need to hash/salt the passwords because our security is that amazing?" 24 hours later someone found an XSS vulnerability in their login page.

 

I remember this! This was the thread obviously the offending party deleted their tweets though

 

How are they not even case sensitive? You'd almost certainly have to do extra work to make them not case sensitive?

Makes sense if employees have to read them over the phone, but sheeeesh. So brutal all around!

Cruft driven development: it's case insensitive somewhere in our insane mess of tools and systems, therefore make it case insensitive in this instance for compatibility.

AKA "I don't have time to clean up my disaster of a living room therefore I can't pick up this pizza box."

I used to use 32-character alphanumeric random strings as answers to secret questions...until I had to read one over the phone.

Rep: Ok, so what street did you grow up on?
Me: Hold on, let me check the random answer in my password manager...
Password manager: ytuu^QoGZc5JQZ4BW3TuvH&w#jLlm%6T
Me: Fuck!
Rep (seeing the same thing on his end): laughter
Me: What if I just tell you it starts with y and ends with T?
Rep: Good enough.

Now I do something like diceware instead.

Hahaha πŸ˜‚

I feel like, this will happen to me soon.

 

"What if we don't need to hash/salt the passwords because our security is that amazing?"

Ooof that is brutal

 

Never take the security opinion of the poor social media manager that is just trying to deal with a deeply technical security question (to them at least) seriously.

I feel bad for the employee who answered this. They are not supposed to have intimate knowledge of security practices and taking their word at face value is demeaning to the security industry.

This doesn't make T-Mobile's practices any better, but it's best not to pile on the wrong person about it.

 

That was T-Mobile, the Austrian branch to be precise, but it led to a chain of asking T-Mobile branches in other countries if they do the same, even made its way to DTAG (the parent company in Germany).

This was really awful, especially considering the reaction from their marketing guys on twitter.

 

Most/all ISPs have had to deal with Challenge-Handshake Authentication Protocol, which requires both sides to know what the password is, not just have something that can be computed from the correct password. It doesn't make the "our security is amazing" comment valid, but does explain why plaintext passwords exist.

 

Maximum password length.

Yes, I had to implement that πŸ€¦β€β™‚οΈ

Also: for debugging purposes, I enabled MySQL logging with the intention of shutting it down once we went live. It logged all SQL commands - yes, the passwords were hashed, but with MySQL's password function, so all passwords appeared in plain text in the log.
My (former) boss: "So, the passwords are hashed in the database and we can't decypher [sic] them, but we're still seeing them with this log?"
Me: "Yes, but..."
My boss: "You know what, I see a solution for all those clients that keep calling for their forgotten passwords..."
Me: "πŸ˜‘"

 

Yes, I had to implement that πŸ€¦β€β™‚οΈ

What was the reasoning here?

 

Because they wanted, for "customers' convenience", the same passwords to work both on the web portal and as their AS/400 passwords. (Customers could also access to the AS/400 terminals.)

Which were limited to 10 EBCDIC characters. 😩

This actually had a glimpse of sense. Because it wasn't like that before. I've just left the passwords unconstrained and happily hashed them into the DB.
"Wait, limit the number of characters to... say, 20."
"What?! Why?"
"Our customers aren't used to passwords that long."

I'm not making this up.

Thinking about that now, there were so many security issues that make my stomach churn. And I'm no security expert!

"Our customers aren't used to passwords that long."

Wait, what?! Why in the heck does that matter? They set their own passwords. They don't have to enter 100-character passwords if they don't want to.

You're assuming I was talking with people that had an idea of what that was all about. 😡

I think I've learnt that people can be that clueless. Even in IT!

 

Pretty much any actual action taken that reduces security is done in the name of convenience. In the case of max password lengths, it could be due to a really naive SQL implementation where there's a max character length in a plaintext field, but it's much more likely that some manager saw that 90% of the help desk time was spent resetting passwords and thought "Well if we make the passwords shorter, people will stop forgetting them."

 

Upper password limits are a sane thing to do, when the limit is high enough. Setting the upper limit to 100 characters allows you to test your system for how it deals with long passwords. Just see my other comment for why you should always make your password set fields a character longer than your maximum accepted password.

 

I'm not sure I'm following you here. Systems just shouldn't have maximum password lengths, period. Passwords should be hashed to fixed-length strings (and that should take a fixed amount of time), so the length of a password shouldn't be a problem, be it 100, 1000 or 314159 characters long. (Well, except for the fact that you're sending a request with a payload of more than 300 kb, but that's another problem...)

Anyway, we were dealing with AS/400 systems with rather old OS versions (5.2 I think), so the upper limit was 10 characters.

In theory, yes, passwords shouldn't have a limit. Password hashing isn't significantly affected by the input size, and storage definitely isn't affected. But what could be affected is your server and application and how they handle long strings. If you want to set the limit to 314159 characters, go for it. Just be sure you test for it too.

I explain the password set field should be 1 character longer than the password entry field here: dev.to/mitchpommers/comment/di2c

 

I was called up for jury duty once. They had a website where I could check on the status of whether I needed to report or not. I couldn't quite remember the URL, so I googled what I could recall and found the status page of...somebody else. There was no actual protection preventing people from getting to anyone else's jury duty call, which included lots of PII. And the IDs of the pages were clearly sequential, so anyone could've written a quick script to download ~300,000 jury duty summons and all the personal info to go with it.

I reported it to the county and they thankfully took it seriously. They told me they worked with the software vendor to fix it...but I never verified, so who knows?

 

Seeing a lot of post-it with passwords all over the offices.

 

Guilty.

When I worked at a small company, we kept passwords of not-often-used-accounts on post-its, but in a coconut cup on our desks. The coconut makes it more secure, obviously.

"What's the password for XYZ again?"

"It's in the coconut"

 

This isn't great, but post-its are more secure than other alternatives...like re-using the same password everywhere.

Your likely attackers are probably not hanging around the office. (Still not ideal, of course)

Password managers are a bit like post-it notes. Maybe you're sitting at a coffee shop, you run to the bathroom ("hey can you watch my stuff for a sec?")β€”it's very possible that someone could snoop onto your computer and expose all your passwords that way.

Again, the person who happens to be sitting next to you at Starbucks is probably not your biggest threat, but you never know.

This is a good point. An out of context password on a sticky note, in my notebook (or in a coconut) isn't a major risk. But, it's also not an ideal habit to have.

Although a good password manager is encrypted, whereas a post-it note probably isn't!

And you can set an auto timeout on good password managers so that after 10s you have to type your password manager password for access.

I think the best way to store passwords is random strings generated by a password manager, imho. Manually copy to manager on mobile and vice-versa to avoid posting via a cloud service. I'm not paranoid, honest! πŸ˜‚πŸ˜‚

 
 

I used to work for a company in a pretty competitive industry, where companies would make it pretty hard for their users to get their data in order to make it harder for them to switch to a competitor.

One of our competitors would just spit out all the data to the front-end as a huge JSON file, which made it easier for us to migrate their users to our platform. The problem is that JSON file contained really sensitive information (hundreds of users' personal info, including credit card numbers). I breathed a secret sigh of relief when they patched that up (even though it made my job harder).

At another company, I was shocked to realize in my first week that they stored all of the passwords in plaintext. One of the first things I did upon joining was to issue an emergency fix to hash the passwords. My manager didn't want to implement it all at once in case it would break things, so he issued it partially where from now on there were two columns in the database, the hashed password and the plaintext one.

The plan was to get rid of the plaintext after some time passed and they were more confident in my solution, but that didn't happen as of the time I left that company...

 

The problem is that JSON file contained really sensitive information

In Rails it's so easy to call .to_json on a model and automatically spit out the whole row of data. Definitely a nightmare of mine.

The plan was to get rid of the plaintext after some time passed and they were more confident in my solution, but that didn't happen as of the time I left that company...

Probably still hasn't happened.

 

Probably still hasn't happened.

At the rate things moved at that place I'll bet that's true...

 

Last April, a local 19 year old was browsing the provincial government's freedom-of-information portal which is the public-facing website for completed FOIPOP (Freedom of Information & Protection of Privacy) requests.

Essentially, anyone can request reasonable information from the government by filling out a form and paying a modest fee; wait a couple weeks, and you'll be given access to said information. It could be one page or several hundred. It could be fully intact or heavily redacted. Completed FOIPOP requests then get posted to a web portal for public interest.

So... While browsing the portal, this 19 year old notices that file IDs are contained within individual page URLs, and they are sequential integers. Instead of clicking through each page of the portal by hand, he writes a script and scrapes 7000 pages from the website--exploiting the sequential numeric IDs.

Exploiting a public website...? Yes, his blitz of activity was noticed by portal administrative staff, the police were called, and he was charged for hacking government infrastructure! (Officially, the criminal code charge was "unauthorized use of a computer".)

Arguably, he should not have slammed the server with 7000 requests in one fell swoop--could be interpreted as a denial-of-service attack. To call his actions "hacking" though is a stretch too far.

Why did government bureaucrats want to see him brought up on charges? Well, it seems that the administrative unit responsible for processing FOIPOP requests and posting them to the portal didn't completely redact sensitive details from files in a portion of its (public!) database. Therefore, in a classic government bungle, the person who stumbled upon this oversight was deemed to be nefarious, meanwhile the government department did what it could to cover up its own failed responsibility in the aftermath.

Charges against the 19 year old "hacker" were eventually dropped and the government freedom-of-information portal was taken offline for an overhaul and security hardening.

Teen charged after personal information exposed in Nova Scotia government website breach (via CBC News, Apr 11/18)

You're a govt official. You accidentally slap personal info on the web. Quick, blame a kid! (via The Register: Security, Apr 18/18)

 

Shared test accounts that can access CI deployments and even deploy, without any clarity of who has access to such accounts.

 

That actually reminds me of an early Facebook anecdote I don't entirely recall the details of, but was something like: There was an admin-level master password they passed around and had no idea who had the password.

Basically early on, the site data was entirely 100% non-secure and they were relying on the hope that the password never truly leaked.

I think I read that in The Facebook Effect book years ago. It doesn't exactly seem out of character based on everything else we now now about the org.

 

Thing is internal/former employees can do a lot of damage if they are determined to, such as sharing trade secrets. Criminal liability and practical inconvenience are bigger reasons most employees don't, rather than any deep security measure.

The threat model looks different for larger companies, or across different jurisdictions.

 

I've recently seen a password.js file used for "authentication" - and yes, it contained the password in cleartext. (While also talking in the comments about state-of-the-art security)

 
 
 

After releasing a rather large project for a client, they gifted me and some other team members these rather fancy backpacks that included the company logo and a key phrase from the project under it.
It was a rather nice gesture, and I took to wearing the backpack. I actually still do, about six years later, it's a really nice backpack.

The look of horror on their acting "head of security" was explained when he told me that the phrase on our backpack was the default root login for all of their development and production servers. Needless to say, they spent the rest of the day updating all of their boxes user credentials.

 

"default root login" made me shudder! Someone needs a privileged access management solution..

 

I've seen much worse than this before, but I found this really humorous - A client I worked for had a JIT RDP solution implemented - you had to request access through a service desk web portal, and have an agent installed on your workstation, and then you could use the built-in Windows RDP to get into the target machine. If you tried without requesting access or having the agent installed, you couldn't connect. I was one of the guinea pigs for this new solution.

So for whatever reason, my agent was really buggy when they put it on my workstation. I noticed that some web pages broke when I had the agent running, and I could no longer RDP into some machines that weren't even governed by the new solution. I realized that the agent could be affecting DNS somehow, and sure enough - the way the agent was "granting access" to the target machine was by adding a DNS entry for the machine. This means it was totally possible to circumvent the access request and agent by just setting your RDP target to the IP address of the machine, not the hostname.

 
 

The software in question probably can block RDP at a level other than just DNS calls, so it's moreso a vault door that's left open with a sign next to it saying "Please don't".

Lol that sounds like something that belongs in Loony Tunes.

 

I did some PHP for a client forum. Account resets sent passwords in plaintext through emails. I notified him that it is a bad practice and very not secure. I proposed solutions but he categorically refused and did not see anything wrong with doing that.

 

I still sometimes receive a plain text password in email when I click forgot password. Then I start hating people there. Ok, you store the passwords probably in clear text. At least don't send it back into the wild.

 

Oh you mean passwords that are already set on the account. Yeah, that's a big no-no.

 

A very large hardware and cloud service re-seller was using unparameterized SQL statements with no other layers of sanitation. Demonstrated to the bosses how 'SELECT * FROM USERS' placed in the Username input field resulted in the table being dumped to the requester... The dump included plain text passwords, credit card numbers, and billing information.

The response to this near criminally flawed level of exposure? 'No one would ever do that. Here, work on this other thing instead.'... I put in my notice that next day.

Fast forward not 3 years and that organization was breached. They are to this day still trying to recover from the damages; both financially and reputation.

Some will say 'why didnt you stay and fix it?'. The organization did not allow engineers to fix things, it was very much a everything for the sale organization. Nothing mattered other than closing the sale. So everything suffered.

I have zero regrets, when I heard about the breach, I laughed, I smiled, I sighed. I felt bad for the team there. I know they got thrown under the bus.

 

Codebase for a large financial institution (to remain unnamed) had explicit SQL injection pathways (among other things).

The architect was told about this. Responded by saying that since the customer (the institution) wasn't explicitly paying for robust security, we would be legally liable if we "try" fix the code to make it more secure - but end up causing more issues or bugs. So, "let's just leave it."

πŸ€·β€β™‚οΈ

 

I was once aware of a website (trying to avoid details here) that stored hundreds of thousands of email addresses, passwords and social security numbers in plaintext and had a search bar for easy lookup. It didn't use HTTPS unless you checked a box on the login form, and the password I used would have been ridiculously easy to figure out.

I told multiple people that this was low hanging fruit for hackers. I don't know if anything changed.

 

To clarify, I didn't choose that password, I just inherited it.

 
 
 

At this point I have to think my SSN is just public info and I’d hope nobody treats it like β€œmy password” in any serious way.

Still worth treating as securely as a password, as you pointed out, but I’d hope it’s used to protect my own security in any way.

 

Pretty much, yes. Worse case it is in a data dump you can buy for a hundred bucks .

 

I once wrote a little extension to our Spam-Filter/Virus-Scanner...

While doing this I needed to inspect the already catched mails and found an e-mail which shocked me a lot... And also ended in someone else gettin fired...

That mail was send by a it-administrator of us who was working for one of our child-companies and was send to all out employees.

Subject: warning! There are dangerous virus-mails going around!

Body:
Please don't open any mail attachments of unknow sender's... Etc. Etc.

PS: I attached an example to this mail

Attachment: an actual malicious mail, containing the original attachment with the original, functional virus...

 

WHAT THE πŸ’©! I get alerting people but GEEZ!

 

In one of my last companies, developers used to set passwords such as "admin", "hello", etc. for their login.

Then the security team set strict policies, so everyone was forced to change their password and the new one should include numbers and special chars. So the devs changed it to "admin@123", "john@123", "jane@123", etc.

After some time, the security team realized that this too was futile, so they forced a password change every month. Now, the devs switched to "jan@123", "feb@123", "mar@123" and so on.

Not to mention, it was a very common practice among devs to share their passwords among each other, sometimes for work related stuff and other times for faking to the telemetry system which calculated hours worked.

 

By some margin the worst I've seen: The accounting department had admin access for pretty much everything within the company and passwords in plain text in a Google Sheet.

I worry something like that is remarkably common, because accounting often needs access to invoices. You'd be surprised how many services have no permission step between "not admin" and "full admin", the latter having access to invoices, so I'd bet a lot of accounting departments have crazy high privileges to mission critical systems. And often no security training at all.

I promptly held a security all-hands, sorted all those privileges and made sure the whole company had a password manager.

I'd urge anyone here to quickly check the practices where you're working. You might find it's a disaster in the making.

 

My first real job was a security nightmare. They used the same easy-to-guess password for everything: "It's this word that is closely related to what we do, but replace the letter o with a zero". When I raised concerns about this practice and suggested we start using a password manager company-wide, they claimed it was secure enough but they'd look into it.

A few months later, we got the new password policy: "The company password is now this other word that's closely related to what we do, but replace the letter i with a 1".

In that same year, multiple of our customer's accounts got hacked, everyone at the company was scrambling to save the data and secure the accounts. No passwords or policies were changed.

 

A multi million dollar client once gave one of their vendors access to their internal API by exposing a node directly to the Internet (plain HTTP with port number and all) and whitelisting the vendor's IP address range

 

Not asking why a permission is needed. The last company I worked for gave you every permission you would ask for. They didn't check if you really needed the permission. I once asked jokingly if I can get the private rsa key for a production server. I wanted to make a joke in that specific situation. A coworker only heard part of it and forwarded my request to the team managing the permissions. I ended up with access to the private key. No one even asked why I would need access.

 

"Checkbox security". It really exposes that your organization's security "experts" aren't. Manifests itself in ways like:

  • System fails a security-scan because it doesn't have IPv6-related security-settings present ...even though you've explicitly wholly-disabled IPv6 on the system
  • A container fails a security-scan because it wasn't built from a "full OS" type starting-point. Never mind that the container is so minimized that it has almost no attack-surface: your IA guy wants you to start with a container that emulates a full Linux distro before you start loading code into it. So, just so the clueless IA guy wants his scanner to work, you have to bloat-out and increase the attack-surface of your container.
  • An RPM (etc.) gets flagged because the RPM version-number makes the (brain-dead) scanner think that you're running Apache 2.4.6 when you're actually running a version that's been patched for all the known flaws. Then you have to explain CVEs and how to update the scanner so it understands that "oh: this particular packaging is actually safe"
  • A security-assessor telling you "you've got too many admin accounts" because you've got uniquely-privileged accounts for each individual service. Explaining, "each one of these accounts has a custom, least-privileges access-profile built into it and each one of these accounts has unique authentication-credentials, if I follow your advice and move to one, uber-admin credential, if an attacker breaks that account, they pwn everything in the enterprise, not just this one system or service-stack"

...The list goes on and on. It's especially frustrating when you're in an organization that says it wants to do risk-based security but none of their designated security "experts" understands actual risk-analysis.

How's this rant relevant: check-box security SME's are far more organizationally-dangerous that someone sharing a password to

 

A couple years ago, I called a "fire" (every drops what they're doing to fix a major issue) because I found a completely unsecured API endpoint that served names, emails, home addresses, and SSNs using sequential IDs. It was fixed in less than a day after I reported it, but I couldn't believe it had been allowed to exist.

Somewhere else, all of engineering shared 1 set of credentials for the Jenkins server, which was accessible via the internet. After I no longer worked there it struck me that not only could I have deleted build configuration for the entire company, they wouldn't be able to find out who did it.

 

I went for an interview at a Startup so I thought it would be better to checkout their application beforehand. Their password reset API was taking two parameters, email address of the account and the new password!!!

It's been three years since I've informed them of this, and they still haven't changed that!

 

Word doc on a network shared drive with all the shared passwords--including bank account info--accessible to anyone in the office. Also, every user's password followed a specific pattern such that anyone could log in as anyone else.

I put a quick stop to all of that.

 

Master password for key company database replicated, in plain text, into 1000s of files in a repo most employees were automatically given read access to.

I once did a grep -r for that password on the shared root ... I had to kill it and cry a little once it'd passed 10,000 hits.

Been a long, long time since I worked there.

 

I worked at a call center in college that handled credit cards for a major provider. Call agents were encouraged to keep a piece of paper at their desk to write down credit card numbers to enter them in to the computer to not interrupt the customer reading it out. We were also encouraged to put the papers in the shredder box at the end of the day, but it wasn't highly enforced. I shredded mine, of course.

 

When I was working for one of the bigger companies in my country they were at the point where security was not even born. They had almost everything wrong. But one of the absolute hits in those days was a white font password hidden on the page where you log in onto the production.

The password had a white-colored font and was just above the login text. It was just a matter of selecting it and copy-pasting to the proper field. This was on a production site and was never fixed.

The other thing I found very confusing that even when we were using Linux at work. Only a few people had their machines encrypted. This was very stupid to work for a security company without encryption or any processes to do so. I have seen that the management had special private screen protection but no disk encryption sic!

 

Our security officer. You read that right, the person responsible for security practices is the worst. Lacks knowledge and skill, and regularly screws up. If we ever get hit by ransom ware, I am quite sure who the source would be.

 

People who take photos of their passwords so they won't forget. They sometimes don't realise that their mobiles can auto-update their social media account galleries. So sometimes you can go to their Facebook profile photos and see the password.

 

Password set fields that have a maximum length equal to the max length password they accept.

If you have a max length, your input fields should allow more characters and then error stating the password is too long. I have seen systems that for reasons (that were valid when the decision was made) had low max password lengths. Newer systems that were built on top of it silently truncated passwords to this max length on both setting and validating, so users thought they had longer passwords than they actually had. Increasing users password lengths then became an issue because you have to allow the increase in both the password set and input fields, but can't because users could then input what they correctly think their password is and recieved an invalid username/password error.

 

Maybe not the worst, but kinda annoying. I recently created an account for an online store and they sent me my password in plain text in the welcome email. I'm totally deleting my account once I receive my order.

 

4 character passwords containing only digits. πŸ€¦β€β™€

 

Wait, what? That wasn't anything we worked on, right?

 

Haha nope, just things I noticed in my last job Henry. ;)

 
 

Using eval in nodejs to evaluate client-side input values. The original developer not only used eval when more sensible approaches existed, but turned off linting multiple times to be able to write it.

One of the few times I legit walked out of the room.


For those unaware this basically meant the original developer jumped through a few hoops to open up the server to server-side code injection, honestly couldn't of been much worse 😒

 

Another one is storing passwords as Strings in your favourite backend language! Strings often stay in memory as constants so can be retrieved in an attack, however if stored as a byte array, and set to null after use, it's then gone immediately.

 

I heard about a company I was considering to apply at that they were using a password manager that an employee had written as their coding interview.
It wasn't possible to have more than 1 admin meaning new employees couldn't be added if the boss was on vacation. It had some grouping but it was used so badly that the AWS root PW was accessible by Every. Employee for a long time. It went on by I think that's enough to give you an idea. Needless to say, I didn't apply..

 

Turk Telekom's homepage for customer accounts defaults to http. It becomes https only on login page. Plus, links to the same thing from their main website still leads to their abandoned old site with an expired certificate 5-6 months ago.

I reported this on Twitter, got contacted by 3 different people on the phone from various tiers, and only response I could get was everything is ok and I should try on a different browser.

1 month fast forward, the pages are still untouched for you to try on a different browser:
Non-https customer home page:
ttmobil.com.tr
Links to abandoned customer site (just pick any option):
bireysel.turktelekom.com.tr/mobil/...

 

I had to make a formal complaint about a problem at my gym.

The manager took me to the gym's main office.

There were five computers in there, all of them turned on and logged in. Customer contact details were visible on one monitor. He gave me a complaint form and a pen, and left me alone in that office for fifteen minutes.

 

The company which sent me my bill every month, inviting me to log in and pay it using my email address and password.

In case I'd forgotten my password, they included it in the email, in plain text.

 

The data from forms filled with precisely the data required for stealing identities (name SSN, address etc), because they were helping people who lost their identity. The data was available in convenient PDF form to the user when logged in. Their data, change the id and someone else's data, pretty much all the data available to any user at all.

 

Password Organizers
A physical notebook to record usernames and passwords in plain text. Because you can only write so many passwords on sticky notes.

etsy.com/listing/200251736/passwor...

 

Working with sensitive data, we back it up on hard drive in a small safe. The safe is not mounted to a wall or anything and anybody can walk in during the day. If timed correctly by a thief, he can walk in the office when everybody is having lunch and just pick up the safe and walk outside with it to open it somewhere more secluded.. Physical security folks, it matters as well!

 

A previous employer didn't properly encrypt user passwords (I left a couple years ago). Admins could view user passwords in plain text, modify them, whatever they wanted. And when I brought it up, I was told the user shouldn't expect their password to be safe and it's on them πŸ€¦πŸ»β€β™‚οΈ

 

I've been seeing bad security practices from a user perspective since I graduated from college. Heck, my wife still wouldn't know a good password if it was stuck in her eye.

But the best worst password will still always be "password." That got a server I managed "hacked" with at least 5 PHP terminal scripts. I left a lovely message for when they tried to load the page after I cleared out the offending files.

 

When I asked to get access/permissions to a dev account, i saw the admin open password.txt. The root account details, creds and password for every AWS account, on their desktop.

Major financial institution.

 

Companies who ignore a β€œhey this is a huge risk and needs to be fixed or everyone could access your data!” And it being ignored. The one I dealt with personally in the past, it was an open api and would have taken just a days worth of work to fix. It included peoples addresses, personal info including their ssn and even now much their checks monthly were.

 

I may or may not work for a company that is still using Node 4 in production...

 
 

worst combination of multiple basic security practices: A major university's student registration system storing user login passwords in clear-text and using student's social security number as record identifier all the while, allowing access to the registration system via the Internet HTTP (unencrypted protocol). These security issues were known for years and exposed during PCI certification (for credit card payment capturing), so guess what else was "in the records" in clear text format?

Classic DEV Post from Jun 13

Async, Parallel, Concurrent Explained - Starring Gordon Ramsay

Complex computing concepts simplified

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. He/Him.