I had a secondary Gmail account with a really nice short nickname (from the early invite/alpha days), forwarded to another of my mailboxes. It had a weak password, leaked as part of one of the many database leaks.

Eventually I noticed some dude in Brazil started using my Gmail, and he changed the password — but I still got a copy of everything he did through the forwarding rule. I caught him bragging to a friend on how he cracked hashes and stole and sold email accounts and user details in bulk.

He used my account as his main email account. Over the years I saw more and more personal details getting through. Eventually I received a mail with a plaintext password... which he also used for a PayPal account, coupled to a Mastercard.

I used a local website to send him a giant expensive bouquet of flowers with a box of chocolates, using his own PayPal and the default shipping address.

I included a card:

"Congratulations on acquiring my Gmail account, even if I'm 7 years late. Thanks for letting me be such an integral part of your life, for letting me know who you are, what you buy, how much you earn, who your family and friends are and where you live. I've surprised your mother with a cruise ticket as you mentioned on Facebook how sorry you were that you forgot her birthday and couldn't buy her a nice present. She seems like a lovely woman. I've also made a $1000 donation in your name to the EFF, to celebrate our distant friendship"

(sensitive parts censored)

Friend: Hey, can you hack my (some website) account?
Me: Depends... What's your username?
Friend: (tells username)
Me: (clicks forgot password?)
Friend: I will give $10 if you do it. There is 2 factor authentication enabled.
Me: (silence) Ok.
Website: Please type the class number you were in in 4th grade.
Me: Hey, did you graduated BLAH elementary school?
Friend: Yeah.
Me: Ahh, I remember. You moved to BLAH elementary school in what grade?
Friend: 4
Me: Hmmm, I don't remember seeing you. What class were you in?
Friend: 5
Me: Well, I now remember. Stupid me. (smirks)
Friend: Haha. (continues to play games beside me)
Me: (Types in 8)
Website: We sent you a password to blah@example.com
Me: (uhh, heads to example.com and clicks forget password?)
Email: Please type the class number you were in in 4th grade.
Me: (wtf is this, types 8)
Email: Please type the teacher's name when you were in in 4th grade.
Me: What was the teacher's name?
Friend: Huh?
Me: When you were in 4th grade.
Friend: Ahh! John Smith.
Me: Ahh, he was strict, right?
Friend: Yeah (continues to play games again)
Me: (Types in John Smith)
Email: Set a new password.
Me: (Types "youaresostupid")
Email: Done!
Me: (copies PLAIN TEXT password from email, logs in to website)
Me: Da-da!
Friend: (gasps)
Me: Money plz~
Friend: Nope.
Me: (wtf, then remembers i changed his email password) Fine then.

=====================

1. There is 2 factor authentication enabled. : Got it?
2. The website sent plaintext password.
3. He is just pure idiot.
4. I didn't got the money.
5. I am now a h4x0r

Just discovered that our student housing rental portal transmits our password in plaintext.

WHAT.THE.ACTUAL.FUCK

When you are resetting your password and the website emails you your current password in plaintext. 🤦

So our public transportation company started to sell tickets online with their brand new fancy​ system.

• You can buy tickets and passes for the price you want
• Passwords are in plaintext
• Communication is through HTTP
• Login state are checked before the password match so you can basically view who is online
• Email password reminders security code can be read from servers response

Oh and I almost forgot admin credentials are FUCKING admin/admin

Who in the fucking name of all gods can commit such idiocracy with a system that would be used by almost millions of people. I hope you will burn in programming hell. Or even worse...

I'm glad I'm having a car and don't have to use that security black hole.

*signs up for Skillshare*
> Sorry, your password is longer than our database's glory hole can handle.
> Please shorten your password cumload to only 64 characters at most, otherwise our database will be unhappy.

Motherf-...

Well, I've got a separate email address from my domain and a unique password for them. So shortening it and risking getting that account stolen by plaintext shit won't really matter, especially since I'm not adding payment details or anything.

*continues through the sign-up process for premium courses, with "no attachments, cancel anytime"*
> You need to provide a credit card to continue with our "free" premium trial.

Yeah fuck you too. I don't even have a credit card. It's quite uncommon in Europe, you know? We don't have magstripe shit that can go below 0 on ya.. well the former we still do but only for compatibility reasons. We mainly use chip technology (which leverages asymmetric cryptography, awesome!) that usually can't go much below 0 here nowadays. Debit cards, not credit cards.

Well, guess it's time to delete that account as well. So much for acquiring fucking knowledge from "experts". Guess I'll have to stick to reading wikis and doing my ducking-fu to select reliable sources, test them and acquire skills of my own. That's how I've done it for years, and that's how it's been working pretty fucking well for me. Unlike this deceptive security clusterfuck!

logger.info(String.Format(" User {0} changed their password from {1} to {2}", username, oldPassword, newPassword))

Production system. Plaintext log.

So I got my email and password delivered to me in plain text..

Time to leave this planet.. 🚀

PLAIN FUCKING TEXT PASSWORD! How can this still be a thing in 2018?

THERE IS NOTHING AS FRUSTRATING AS WAITING FOR A RESET PASSWORD MAIL... ONLY TO GET A STREAM OF 16 PLAINTEXT PASSWORDS 30 MINUTES LATER, WITH NONE OF THEM WORKING.

Fuck you, IKEA. 🖕

A website just emailed me my forgotten password in PLAINTEXT.

I'm out of breath from running for the hills so fast.

Just wow. I am amazed by what just happened.

A year ago my parents decided to switch from desktop to laptop for convenience. Knowing their needs, i bought them one without an OS and installed Ubuntu 16.04 on it. The thing is that if you do a regular maintenance of the laptop once a year at their partner company, you get additional 4 years of warranty (this offer is amazing).

So today was the day I brought the laptop for this maintenance for the first time. They make you a profile on their support website where you can track shit regarding your device, super convenient. First thing I notice that the login page was not https. Awkward, but there is no sensitive data here so i let it pass. Naturally i forgot my password, so I requested a new one and guess what? I recieved it in plaintext via mail. A tech repair oriented company does this, my god.

I went there, gave them the laptop in question and got a piece of paper, where they wrote that the laptop is in their hands now, and the current physical state of the laptop, and blabla.

I got home and I read what the guy wrote among other things: THE OPERATING SYSTEM IS NOT LEGAL.

How the fuck is Ubuntu not legal??? What the fuck is this shit? I sure as hell didn't torrent it or bought a booteged copy on the streets.

I used PHPMailer to send emails to a client's website user. SMTP host is smtp.gmail.com.

web was hosted on Bluehost. I found out that mailer was not working. I enabled verbose output and to my surprise I found out that Bluehost was intercepting my mail and responding with

220-We do not authorize the use of this system to transport unsolicited, 220 and/or bulk e-mail

when i was explicitly using smtp.gmail.com. Not only they were intercepting but also They were trying my credentials against its own smtp server and then showing me that authentication failed.

When i contacted chat they asked me to tell last 4 characters of Bluehost account password to verify ownership.

Dude do they have passwords in plaintext.🤔

About a year ago I switched my job.
At the start everything seemed like magic. I was the It director, I've finally was able to call the shots on technologies, on new software architecture.
First step was to check the current state of the company.
"qqqq" as each pc password? Ok
No firewall from outside? Lovely
Servers running on Windows Server 2008? Spectacular
People leaving pc on after work and left the machine unlocked just not to type the password? Hell yeah
The IT dude playing games instead of working? But ofcourse
Plaintext passwords publically accessible eshop? Naturally.
The list goes on and on.
After all this time, I'm working to fix every hole like that like crazy and because it doesn't show results, I'm soon to lose my job. Well better luck next time as an intern I guess :')

Today Comcast told me my account password over the phone... Fucking Comcast stores passwords in plaintext.

Something I probably shouldn't talk about:

One of the projects at work has a specific path you can visit. The """security""" is that nobody should know the path. But I can guaran-fucking-tee you it's not difficult to guess.

On this page, ***without a login***, you can view some user information. Well, you can view all of it, but only certain fields.

And if you perform a specific action on this page, you can get their password, plaintext.

This project is not mine. But learning all of this made me super uneasy. I had to share it.

Sites that store plaintext passwords in 2017...

My parents are real sticklers for who is allowed to be on Netflix. They only let people on when they are present, and they never click 'save password'.

Me being a poor college student and desperate for the Netflix password, created a fake website for one of my parents to sign into.

How did I do this? I created my own localhost server with a backend database for the password to go to. I then copied the Netflix home screen and log in and asked them to log me into their account.

They said I can be on for one hour, and then they were signing me out.

I agreed to these terms.

As a small twist, I had also copied the no internet tab from Chrome for the page to redirect to. Knowing that once they logged in they would be expecting the main UI.

They logged in and then waited for the page to load. I, of course, put in a delay for the page to load and then displayed the no internet tab. They were confused and asked me to refresh, still nothing. I asked them if the router was out, and they went to check.

While they were away I quickly switched back to the real Netflix website and yelled back saying I got it working again. They came back over and saw that it was asking for a password again. They signed in and saw the main homepage and none were the wiser that day.

Once they left I checked inside the DB and found the plaintext password they typed in... The damn password was so simple, I cursed myself for not having figured it out sooner. No matter, I had my parents Netflix password.

So you're probably wondering how they didn't see the URL above and think something was off?

I pressed F11 and fullscreened my entire browser. They did ask, and I simply replied with, I don't like seeing all the crap up above when I'm streaming. No further questions, perhaps I was lucky.

Finally got a new job, but it's already a horror story not even 2 hours in (making this while on break)

Everyone here is an Intern, IT? Interns, Designers? Interns, HR? Interns.

The Person who I should've worked with got fired yesterday, and now I have to work all of his shit up from 0, Documentation? Fragmental, a few things here and there, but nothing really.

IT security also doesn't exist in the slightest, there is an Excel sheet called "Master_Passwords" and every single password is in Plaintext, written out for everyone to see. (at least they used "strong" passwords)

And the place also looks run down, theres PC's, Laptops, Mics, Cables etc. lying literally everywhere no-one knows what works and what doesn't (since everyone is an intern)

Not to mention the "Server Room" is an absolute mess itself, cables hanging from literally anywhere, powerstrips are ontop of servers, each rack has like 2 or 3 2U Servers, (in a 40u Rack) and there are 10 of them!

Are there any website or public list that shame companies and websites for sending passwords in plaintext whenever we tend to reset the password?

Seriously, fuck that incompetent ISP of mine.

Stores passwords in fucking plaintext. Does VoIP calling in plaintext! Passwords are sent over postal mail! Passwords are at least not sent in plain via email anymore when you want to reset them. The password reset form, "cannot contain `", "cannot contain "", "cannot contain '", "must contain a special character" because why the fuck not mess with people's password manager's password generation function over our own incompetence, right?! And showing all those errors for a single password? Eh, no. Let's just show one error that applies to whatever password you've given at that time. JUST ONE, because "reasons"! And to top it all off, when I finally made myself a nice password with some padding to remove unwanted chars and put that in my password store and on the website. THE BLOODY THING CAN'T EVEN FUCKING LOGIN?!

Now I ain't no ISP, but being a sysadmin clearly isn't a requirement when you're going to apply for work at an ISP, THAT DOES NOTHING BUT FUCKING SYSADMIN STUFF!!! Incompetent pieces of SHIT!!!

I just got sent an email after registering an account at a webshop which contained my username and password.. *sigh*

About browsers and whole SSL CERT thing...

Most likely everyone here noticed, that https site with broken certificate will throw these big red warnings, in your face and there is so much wording like "ITS NOT SECUREEEE" or "ITS HACKEDDD" almost like it was written by passionate fanatic.

But when you are on plaintext http browsers reaction is like ¯\_(ツ)_/¯
Even if you have plaintext with password, it will for example in chromium put small little red thingy that almost no one notices.

I believe that broken cert with some error like invalid date is MORE secure than plaintext password, yet still there is this hypocracy with browsers...

I dont say that broken SSL cert is good, or something, Im just pointing out contrast of "broken" https vs plain http.... One looks for casual Joe like end of the world is coming and second is bearly noticable. Da fuck?

I disagree with this approach

Once upon a time, in a proprietary e-commerce framework used by few hundred sites...

I just took over a project where the previous developer stored password in two separate fields.

password & password_visible

First was encrypted and used for authentication. Second was plaintext password and was shown in the admin panel.

Hope to meet this god someday, I'd sure ask why the hell did he use encrypted password for authentication anyway. 😂

I forgot my password to [SITE]. Of course, I click "forgot password", and enter my email, which I did remember. Fairly routine "ah shit we have a problem" steps.

Now, it takes a second. This is to be expected. So I'm not worried. I then get the email and...

Now, you will notice that I redacted some information, like the company name, email, and my PLAIN TEXT PASSWORD, and my name.

I would like to note that this isn't a small, very local company that's new (even then it'd be unacceptable), but this is a multinational, multimillion dollar company.
How'd someone fuck up THIS badly?

stored username and password in a cookie .... in plaintext

*speaks from my partner's point of view*

These dimwits emailed my receipt for my dues (not shown) AND MY USERNAME AND PASSWORD in the same PLAINTEXT UNENCRYPTED email...

Off to go write a cranky email...

Created an account on Juststickers.
This is the email I get

Oh my fucking god people are stupid, or ignorant, or fucking both.

How hard is it to copy a password from an email and paste that fucker in and press login.
Seriously several times of “this is your email” and “THIS” is your god dam fucking password.
God kill me now.

(No the password isn’t stored in plaintext, I reset it myself before sending it to the user)

Thank you, dear 3rd party vendor replying to my ticket to my work email and sending me my new password IN FUCKING PLAINTEXT!

Oh boy, this is gonna be good:

TL;DR: Digital bailiffs are vulnerable as fuck

So, apparently some debt has come back haunting me, it's a somewhat hefty clai and for the average employee this means a lot, it means a lot to me as well but currently things are looking better so i can pay it jsut like that. However, and this is where it's gonna get good:

The Bailiff sent their first contact by mail, on my company address instead of my personal one (its's important since the debt is on a personal record, not company's) but okay, whatever. So they send me a copy of their court appeal, claiming that "according to our data, you are debtor of this debt". with a URL to their portal with a USERNAME and a PASSWORD in cleartext to the message.
Okay, i thought we were passed sending creds in plaintext to people and use tokenized URL's for initiating a login (siilar to email verification links) but okay! Let's pretend we're a dumbfuck average joe sweating already from the bailiff claims and sweating already by attempting to use the computer for something useful instead of just social media junk, vidya and porn.

So i click on the link (of course with noscript and network graph enabled and general security precautions) and UHOH, already a first red flag: The link redirects to a plain http site with NOT username and password: But other fields called OGM and dossiernumer AND it requires you to fill in your age???
Filling in the received username and password obviously does not work and when inspecting the page... oh boy!

This is a clusterfuck of javascript files that do horrible things, i'm no expert in frontend but nothing from the homebrewn stuff i inspect seems to be proper coding... Okay... Anyways, we keep pretending we're dumbasses and let's move on.

I ask for the seemingly "new" credentials and i receive new credentials again, no tokenized URL. okay.

Now Once i log in i get a horrible looking screen still made in the 90's or early 2000's which just contains: the claimaint, a pie chart in big red for amount unpaid, a box which allows you to write an - i suspect unsanitized - text block input field and... NO DATA! The bailiff STILL cannot show what the documents are as evidence for the claim!

Now we stop being the pretending dumbassery and inspect what's going on: A 'customer portal' that does not redirect to a secure webpage, credentials in plaintext and not even working, and the portal seems to have various calls to various domains i hardly seem to think they can be associated with bailiff operations, but more marketing and such... The portal does not show any of the - required by law - data supporting the claim, and it contains nothing in the user interface showing as such.
The portal is being developed by some company claiming to be "specialized in bailiff software" and oh boy oh boy..they're fucked because...

The GDPR requirements.. .they comply to none of them. And there is no way to request support nor to file a complaint nor to request access to the actual data. No DPO, no dedicated email addresses, nothing.

But this is really the ham: The amount on their portal as claimed debt is completely different from the one they came for today, for the sae benefactor! In Belgium, this is considered illegal and is reason enough to completely make the claim void. the siple reason is that it's unjust for the debtor to assess which amount he has to pay, and obviously bailiffs want to make the people pay the highest amount.

So, i sent the bailiff a business proposal to hire me as an expert to tackle these issues and even sent him a commercial bonus of a reduction of my consultancy fees with the amount of the bailiff claim! Not being sneery or angry, but a polite constructive proposal (which will be entirely to my benefit)

So, basically what i want to say is, when life gives you lemons, use your brain and start making lemonade, and with the rest create fertilizer and whatnot and sent it to the lemonthrower, and make him drink it and tell to you it was "yummy yummy i got my own lemons in my tummy"

So, instead of ranting and being angry and such... i simply sent an email to the bailiff, pointing out various issues (the ones

Creating username / password first time - checked
Storing password in plaintext - checked
Messaging password in plain text after a password change - whaaattt????

Signed up for a market research company (ironically, that I used to work for as a transcriber about 10 years ago) to pull in a bit of extra cash.

They sent an e-mail back confirming my registration.

With the password in plaintext.

sure.... That seems a reasonable arrangement of Gibberish =_=

Have been using redis for my new system and wanted to try some gui, so I stumbled on "redis desktop manager", it supports ssh tunnels, privatekeys and more, great isn't it?

BUT IT SAVES YOUR FUCKING PLAINTEXT PASSWORD AND PATH TO YOUR PRIVATE KEY IN %USER%\.rdm\connections.json

WHAT THE FUCK, fucking ask that password during connection, don't fucking save it in plaintext and give an attacker literally the path to my key, wanted to PR it, but fuck c++, probably thats why he doesnt have it, because hes just using some library, so he doesn't have to fuck with the actual implementation of it.

I'd never do anything "risky" in a prod environment if I considered it so at the time, but in retrospect there's *lots* of things considered risky now (both from a security and good practice viewpoint) that were standard practice not long ago:

- Not using any form of version control
- No tests (including no unit tests)
- Not considering XSS vulnerabilities
- Completely ignoring CSRF vulnerabilities
- Storing passwords as unsalted MD5 hashes (heck that was considered very *secure* in the days of plaintext password storage.)

...etc. I'm guilty of all of those previously. I daresay in the future there will be yet more things that may be standard practice now, but become taboos we look back on with similar disdain.

Social Captain (a service to increase a user's Instagram followers) has exposed thousands of Instagram account passwords. The company says it helps thousands of users to grow their Instagram follower counts by connecting their accounts to its platform. Users are asked to enter their Instagram username and password into the platform to get started.

According to TechCrunch : Social Captain was storing the passwords of linked Instagram accounts in unencrypted plaintext. Any user who viewed the web page source code on their Social Captain profile page could see their Instagram username and password in plain text, as they had connected their account to the platform. A website bug allowed anyone access to any Social Captain user's profile without having to log in ; simply plugging in a user's unique account ID into the company's web address would grant access to their Social Captain account and their Instagram login credentials. Because the user account IDs were for the most part sequential, it was possible to access any user's account and view their Instagram password and other account information easily. The security researcher who reported the vulnerability provided a spreadsheet of about 10,000 scraped user accounts to TechCrunch.

My university has a internal developed system, where everything is managed from e-mails, exams to personal data.

What I'd like most about it, they talk all day about Internet Security and store our passwords in plain text and if you press the "I've forgott my Password button", they even send your password unencrypted, plaintext via e-mail. (Hello Wiresharks)

I don't know how to feel about this, it just hurts :(

Client asked us to modify site made in some obscure CMS. Authentication on AJAX request is done by sending email and password as plaintext in header and then it would do md5 on server side

Hang on... If online banks ask you for the n'th, m'th and p'th character of your password, they must be storing it on plaintext! WTF? I don't even understand why they do that in the first place.

Dear Arch Linux Maintainers. Why the fuck are you sending me my password in plaintext?! Not enough: You are sending me my fucking password every fucking month, so i do not forget it, because its important!??!?!?! WHAT THE FUCK! Fucking idiots...

ZNC shenanigans yesterday...

So, yesterday in the midst a massive heat wave I went ahead, booze in hand, to install myself an IRC bouncer called ZNC. All goes well, it gets its own little container, VPN connection, own user, yada yada yada.. a nice configuration system-wise.

But then comes ZNC. Installed it a few times actually, and failed a fair few times too. Apparently Chrome and Firefox block port 6697 for ZNC's web interface outright. Firefox allows you to override it manually, Chrome flat out refuses to do anything with it. Thank you for this amazing level of protection Google. I didn't notice a thing. Thank you so much for treating me like a goddamn user. You know Google, it felt a lot like those plastic nightmares in electronics, ultrasonic welding, gluing shit in (oh that reminds me of the Nexus 6P, but let's not go there).. Google, you are amazing. Best billion dollar company I've ever seen. Anyway.

So I installed ZNC, moved the client to bouncer connection to port 8080 eventually, and it somewhat worked. Though apparently ZNC in its infinite wisdom does both web interface and IRC itself on the same port. How they do it, no idea. But somehow they do.

And now comes the good part.. configuration of this complete and utter piece of shit, ZNC. So I added my Freenode username, password, yada yada yada.. turns out that ZNC in its infinite wisdom puts the password on the stdout. Reminded me a lot about my ISP sending me my password via postal mail. You know, it's one thing that your application knows the plaintext password, but it's something else entirely to openly share that you do. If anything it tells them that something is seriously wrong but fuck! You don't put passwords on the goddamn stdout!

But it doesn't end there. The default configuration it did for Freenode was a server password. Now, you can usually use 3 ways to authenticate, each with their advantages and disadvantages. These are server password, SASL and NickServ. SASL is widely regarded to be the best option and if it's supported by the IRC server, that's what everyone should use. Server password and NickServ are pretty much fallback.

So, plaintext password, default server password instead of SASL, what else.. oh, yeah. ZNC would be a server, right. Something that runs pretty much forever, 24/7. So you'd probably expect there to be a systemd unit for it... Except, nope, there isn't. The ZNC project recommends that you launch it from the crontab. Let that sink in for a moment.. the fucking crontab. For initializing services. My whole life as a sysadmin was a lie. Cron is now an init system.

Fortunately that's about all I recall to be wrong with this thing. But there's a few things that I really want to tell any greenhorn developers out there... Always look at best practices. Never take shortcuts. The right way is going to be the best way 99% of the time. That way you don't have to go back and fix it. Do your app modularly so that a fix can be done quickly and easily. Store passwords securely and if you can't, let the user know and offer alternatives. Don't put it on the stdout. Always assume that your users will go with default options when in doubt. I love tweaking but defaults should always be sane ones.

One more thing that's mostly a jab. The ZNC software is hosted on a .in domain, which would.. quite honestly.. explain a lot. Is India becoming the next Chinese manufacturers for software? Except that in India the internet access is not restricted despite their civilization perhaps not being fully ready for it yet. India, develop and develop properly. It will take a while but you'll get there. But please don't put atrocities like this into the world. Lastly, I know it's hard and I've been there with my own distribution project too. Accept feedback. It's rough, but it is valuable. Listen to the people that criticize your project.

So here I am investigating something our users are claiming. I look up which user the UserId did the change and I see not only the user but also the users password in clear text in a separate field. I thought that field was for a password hint that the user can set up, but I asked around and apparently, no... It's literally the plain text version of the password stored in the database, next to the hash of the password.
Apparently, the users were so impossible to deal with that we added that column and for users that constantly pester us about not knowing their password and not wanting to change it, we added a plaintext password field for them :D

***ILLEGAL***
so its IPL(cricket) season in india, there is a OTT service called hotstar (its like netflix of india), the cricket streams exclusively on hotstar..
so a quick google search reveals literally thousands of emails & passwords, found a pastebin containing 500 emails&passwords ...but those are leaked last year most of passwords are changed & many of them enabled 2FA.. after looking through them we can find some passwords are similar to their emails , some contains birth year like 1975,1997 etc, some passwords end with 123 ..so after trying a few different versions of the passwords like
1) password123 -> password@123, password1234
2) passwordyear -> password@year
2) for passwords similar to emails, we can add 123 ,1234, @ etc
created a quick python script for sending login requests

so after like 30-40 mins of work, i have 7 working accounts

*for those who have basic idea of security practices you can skip this part

lessons learnt
1) enable 2FA
2) use strong passwords, if you change your password , new password should be very different from the old one

there are several thousands of leaked plaintext passwords for services like netflix,spotify, hulu etc, are easily available using simple google search,
after looking through & analysing thousands of them you can find many common passwords , common patterns
they may not be as obvious as password ,password123 but they are easily guessable.
mainly this is because these type of entertainment services are used by the average joe, they dont care about strong passwords, 2FA etc

I've always thought I was somewhat lazy about not caring about plaintext password in RAM in WPF (or whatever) but then this guy made a super valid point...

I really think a hacker would just keylog at that point rather than trying to read your obscure program's memory for your password... especially if they have access to raw memory...

If you think parametised queries will save the day think again.

I occasionally test sites I visit throwing a few quotes at inputs and query params.

I also always test logging in as % with user or pass.

Not only are plaintext passwords a thing but so is this:

WHERE username LIKE ? AND password LIKE ?.

Once I saw an OR.

- i registered at ***.com (pet store) with a super secure password and then they send me a welcome email with the password in plaintext...
- well, it sucks to have pets

Who the fuck congratulates themselves over email sent to others, these are the fuckers that will probably send you password in plaintext when you want to recover it.

Compare against hardcoded plaintext password...
In Javascript...

Signed up for an account on an online store, which then proceeded to send me my full password in plaintext, and in an unencrypted email.

Sent them an email 3 weeks ago detailing the security issue (i was extremely nice about it), but no response.

What else can i do?

I changed my twitter password on web on the day they discovered the passwords in plaintext in their logs, and till today, I've not been logged out of the mobile client

So I received an email from IEEE with my account credentials in plaintext and properly labelled as username and password.

The importance of not using static salt / IVs.

I've been working on a project that encrypts files using a user-provided password as key. This is done on the local machine which presents some challenges which aren't present on a hosted environment. I can't generate random salt / IVs and store them securely in my database. There's no secure way to store them - they would always end up on the client machine in plain text.

A naive approach would be to use static data as salt and IV. This is horrendously harmful to your security for the reason of rainbow tables.

If your encryption system is deterministic in the sense that encrypting / hashing the same string results in the same output each time, you can just compile a massive data set of input -> output and search it in no time flat, making it trivial to reverse engineer whatever password the user input so long as it's in the table.

For this reason, the IVs and salt are paramount. Because even if you generate and store the IVs and salt on the user's computer in plaintext, it doesn't reveal your key, but *does* make sure that your hashing / encryption isn't able to be looked up in a table

So, I ran a test on one of the education websites I'm currently using (AT SCHOOL!!) To see how secure they are...... They sent me my password in plaintext FFS!

Relatively often the OpenLDAP server (slapd) behaves a bit strange.

While it is little bit slow (I didn't do a benchmark but Active Directory seemed to be a bit faster but has other quirks is Windows only) with a small amount of users it's fine. slapd is the reference implementation of the LDAP protocol and I didn't expect it to be much better.

Some years ago slapd migrated to a different configuration style - instead of a configuration file and a required restart after every change made, it now uses an additional database for "live" configuration which also allows the deployment of multiple servers with the same configuration (I guess this is nice for larger setups). Many documentations online do not reflect the new configuration and so using the new configuration style requires some knowledge of LDAP itself.
It is possible to revert to the old file based method but the possibility might be removed by any future version - and restarts may take a little bit longer. So I guess, don't do that?

To access the configuration over the network (only using the command line on the server to edit the configuration is sometimes a bit... annoying) an additional internal user has to be created in the configuration database (while working on the local machine as root you are authenticated over a unix domain socket). I mean, I had to creat an administration user during the installation of the service but apparently this only for the main database...

The password in the configuration can be hashed as usual - but strangely it does only accept hashes of some passwords (a hashed version of "123456" is accepted but not hashes of different password, I mean what the...?) so I have to use a single plaintext password... (secure password hashing works for normal user and normal admin accounts).

But even worse are the default logging options: By default (atleast on Debian) the log level is set to DEBUG. Additionally if slapd detects optimization opportunities it writes them to the logs - at least once per connection, if not per query. Together with an application that did alot of connections and queries (this was not intendet and got fixed later) THIS RESULTED IN 32 GB LOG FILES IN ≤ 24 HOURS! - enough to fill up the disk and to crash other services (lessons learned: add more monitoring, monitoring, and monitoring and /var/log should be an extra partition). I mean logging optimization hints is certainly nice - it runs faster now (again, I did not do any benchmarks) - but ther verbosity was way too high.

The worst parts are the error messages: When entering a query string with a syntax errors, slapd returns the error code 80 without any additional text - the documentation reveals SO MUCH BETTER meaning: "other error", THIS IS SO HELPFULL... In the end I was able to find the reason why the input was rejected but in my experience the most error messages are little bit more precise.

Super old affiliate management tool that wasn't updated since 2010 and stored all password in plaintext, including all coworker's and ceo's. I'm pretty sure it had some vulnerabilities to get those passwords from the outside as it was just a shitty piece of software. After finding that database it had to stay online for about a year against my recommendation until we had the chance to build an alternative.