Got any similarly tales?
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Top 10 Tips with Code Examples: C# Application Security
ByteHide -
5 AI-Powered Content Detectors to Help Identify AI-Generated Text
Joy Winter -
Tether & USDC: The Backbone of 2024's Stablecoin Surge Amid Security Concerns
soma -
Why "AI" is the new "sustainable"
Ingo Steinke, web developer -
Top comments (162)
Two things that drive me absolutely nuts.
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 π
Genius!!!!
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.
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.
Simple enough: remove people :D
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.
I love it π
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 π
macOS encrypted folder
Glenn Carremans γ» Mar 20 γ» 2 min read
It woulnt be slow if encrypted?
Yeah but it's barely noticeable on a Mac.
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.
leaving the computer unlocked and unattended also drive me nuts, especially when the dev has access to production and aws sdk with broad permissions... depending on teams we had different rules.
What we did the most was changing the desktop/lock screen with something very very ugly and embarrassing (which they had to keep for a whole week). This is a kind of personal intrusion and we did that only in teams where we had lots of confidence with each other, but it clearly shows how much control you can take over someoneΒ΄s computer.
Sometimes we simply applied the cookie/cake/pizza rule via a message on slack from the persons computer "Hi, everybody, I love my team and tomorrow I will bring pizza for everybody!"
Currently with I sometimes do is just opening lockyourscreen.com/ on their browser... quite funny.
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%6TMe: Fuck!
Rep (seeing the same thing on his end): laughter
Me: What if I just tell you it starts with
yand ends withT?Rep: Good enough.
Now I do something like diceware instead.
Hahaha π
I feel like, this will happen to me soon.
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
passwordfunction, 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: "π"
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!
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!
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
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! ππ
[at] Ben Halpern - You would be surprised to see how many attackers are actually in the offices.
I walk around the office somewhat regularly and destroy any password post-its I find.
Thats awesome!
At least leave a donut behind.
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?
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...
In Rails it's so easy to call
.to_jsonon a model and automatically spit out the whole row of data. Definitely a nightmare of mine.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)
I've recently seen a
password.jsfile used for "authentication" - and yes, it contained the password in cleartext. (While also talking in the comments about state-of-the-art security)π€―
Please tell me it wasn't also checked in...
It was publicly reachable from the interwebs ;)
π
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.
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..