// Detect dark theme
var iframe = document.getElementById('tweet-1156194610751901701-921');
if (document.body.className.includes('dark-the...
For further actions, you may consider blocking this person and/or reporting abuse
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
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 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%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 ;)
π
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..
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 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 saleorganization. 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.
Using some simple Google-foo, you can find all the public Trello boards people are using to store and share community account passwords:
Holy hell!
Yup. Keep all your Trello boards private!
Just OMG!
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.
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.
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!
SSNs in an email. Why would you do that?
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 should add these were SSNs of clients/customers.
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
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.
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:
...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.
Lol that sounds like something that belongs in Loony Tunes.
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.
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 -rfor 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.
Are you describing a backdoor without a lock?
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. ;)
π°
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.
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.
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!
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.
Using
evalin nodejs to evaluate client-side input values. The original developer not only usedevalwhen 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 π’
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 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...
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?
Some companies enforce (through CAA policy) the use of a certification authority of their choice to make ssl certificates.
While i was hosting a web site for them, i told them i had automatic renewal setup through an acme client (using letsencrypt).
They wouldn't change their mind, and since they had no way to do automatic renewal, they'll mail me the website certificates whenever they expire :(
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.
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.
A client to who we built and handled the eCommerce website for, their tech in their company installed a cracked plugin instead of paying 20$ and the cracked version was backdoored.
This resulted in the whole website being compromised and thus it had to be shut down for a few days and this was an important revenue loss.
More information here: dolohem wordpress malware
Banks still requiring IE to sign in to secure banking (corp account, though you also need a smart card ) as their software does not work with normal browsers and there other option firefox ESR is hit and miss but more miss.
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..
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.
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 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.
I may or may not work for a company that is still using Node 4 in production...
What are the reasons not to upgrade to a recent LTS release?
"too much other stuff to do"
admin admin
MySQL server listening on 0.0.0.0 with no firewall and the main database inside. I still shudder to this day.
In the early days of web development many people stored database secrets in *.inc files which were then included with PHP.
Unfortunately those *.inc files were publicly accessible because the Apache web server served them as plain text.
Another company I worked for was storing plain text passwords so that internal customer service reps could have a page that would allow them to log in and impersonate customers (to fix issues, etc.).
Oh ya, the password was passed - in plain text - in a query string as part of the link.
Good news is that it has since been fixed.
π€·ββοΈ
I was at a meeting once sitting next to an SVP of a major company, he made no effort to hide his 0000 iPhone pass code. my password is 36 charters with capitals, lowercase, and numbers, all because of that.
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/...
This might not be a "bad security practice" but rather a fear of mine. I'm always wondering how people can work at coffee shops or other public places. I couldn't possibly be productive in an environment where random people hang out behind my back. At least I would have to attach a laptop screen guard, put on noise-canceling headphones and back off into a corner back to wall to be comfortable.
Once found someone sending a SQL query from JavaScript to an API for execution on the server. Yes, they wrote the query on the frontend.
(Yes, I did try to do a little poking around, but not enough to mess with anything! And yeah, you could do whatever queries you wanted. Nothing was escaped, either.)
Good news: we have logging in our web application! Bad news: we were logging all post requests which included customer passwords, credit cards, and adresses....
Apparently, we had been doing this for years and I was the only one to recognize the phrasing "Yeah, we log post requests as well" as indicating a potentially horrifying situation.
This true story I've met recently.
When I took over the database tables generated by -x developers in 2017, I found that he used the MD5 hash to store user passwords.
Oh God! I want to tell him it has the security issue, but he said: Most of PHP web applications uses MD5 hash to store passwords in database tables.
I want to share the web sited called phptherightway, but he leaves our team and works for another company now.....
My ex worked for a major international hotel in Mexico.
They stored ALL credit card information in plain text on a desktop of a lobby computer. That was used for customers booking over the phone. And that was roughly 15 years ago.
Just last month I got an account creation confirmation over email with my username and password. In 2019 there are still websites that do not hash passwords.
Everyone should install plaintextoffenders.com/ and stop using anything on that list!
I mean, this was wild (but not that surprising at this point)
Facebook stored hundreds of millions of passwords in plaintext
Ben Halpern γ» Mar 21 γ» 1 min read
GET /auth?username=bob&password=foobarMaking all DB instances (production & dev) reachable from everywhere because "they are user/password protected".
I worked for a small company that had really basic passwords for pretty much everything running their business. I could still get into things b/c they haven't changed passwords π€¦π»ββοΈ
Password requirement of exactly 8 characters, alphanumeric only, hashed with sha1. This was about 4 years ago
Giving modification passwords to a production schema to someone, and when the person is let go and rehired in another department, the password is only then changed.
So they had the insight to change the password when they saw the person re-hired but never thought to have it be part of the exit process?
Yeah. That process changed afterwards, no one gets access to production schemas like that anymore.
When the password is
passwordwith numbers replacing obvious letters for a surprising amount of accounts/private wifi networks. :)password written on a posti-it on the computer
The entire company used the same password for everything. That password was also the CEO's password for everything. Including their bank. Plus, they had employee turnover every year or less.
Facebook keeps password as a plain text.
DB Passwords on the controller.
Active user accounts with access to internal resources for people that had left the company years ago
Every time a website doesn't allow the full range of Unicode characters and insists on passwords shorter than 15 length, I know that's a place waiting to be brute forced.
Oh boy...
A company division would upload its online orders in a unencrypted CSV file to their anonymous FTP server so HQ could fetch it nightly for further processing.
Using the password to a DB that was the reverse of the user for password.
appdev
vedppa
nothing was changed and used on multiple systems.