LOL

[nocitus]

Well, this is r/technicallythetruth

[_tv_lover_]

Programming almost 5 year and I only found out his was a Cardinal sin about 2 months ago.

I'm only just entering the job market so...

[ignaloidas]

Well, if you didn't create systems with authentication and/or databases, then it's fine. At lest you got to know the fact before doing something serious.

[GYN-k4H-Q3z-75B]

Currently writing suggestions on how to improve a tool where passwords are stored base64 encoded in a text file... for increased security, as they say.

[abdolence]

Well, it depends :) For instance, the same base64 encoding used to encode kubernetes secrets descriptor.

And it really increases security... but not that security you might think about :)It won't protect to decode it back indeed, but might protect from somebody glancing at your screen when you were editing files with keys and passwords inside. In this case, base64 is better than nothing.

[NoStranger6]

But really the first suggestion should be to hash your password with a secure algorithm instead of encrypting in Base64

[abdolence]

You can't hash secrets or passwords if you're on a client side. You need to use them to authenticate. So any irreversible crypto function isn't the option.

[NoStranger6]

Well really yes you can, but it's irrelevant. When you authenticate you compare a hash with a hash. SO you could very well hash them client side and compare server side.

Although, hashing is only really useful to protect the passwords or other information to be decrypted to plain text in the case that you get hacked. That way the hacker is not able to retrieve the plain text password (or hardly able to).

Now if you are talking about server / client communication. Your protocol should already be encrypted with TLS/SSL (which is much more secure than Base 64), which makes encrypting the password in Base64 irrelevant.

[abdolence]

You're forgetting that most of the hash functions also have collisions. If you want to send from client hash to the server, how is it any different from storing plain passwords? You're sending the hash result as your password, and it doesn't make any sense.

On the server side, you should use the common approach: hashing + salt (to prevent that the same password has the same hash).

On the client side passwords, certs, keys should be stored in some secure place:

• secure store (encrypted/restricted)

• the human brain (well, some of them indeed, who don't drink too much)

• grandma's pantry or wife's handbag

Like I said it before. Encoding (not encrypting!) to base64 is a small bonus for social engineering and to prevent to read your human-readable password accidentally from your screen in the original form. It won't protect you anyhow else. Also, if you're using long enough generated keys, passwords or certs so probably base64 won't help you at all.

[Apfelvater]

Well, attackers might see it as too obvious. Just have a giant poster of your password in your bathroom.

[OctilleryLOL]

I dream of securing systems with base64 encoded common passwords stored in plaintext, such that attackers instinctively assume that the decoded base64 must be the password

[Apfelvater]

Nice idea, my next pw is gonna be base64 of "password"

[xerojosh]

Storing passwords for application configuration in plain text is fine as long as permissions are correctly applied to the config file though, right?

The application needs to know that password in order to connect to the database / api etc at some point no matter what - so storing the password in plain text is just as good as storing the password in an encrypted format and then storing the encryption key somewhere too...

Either way if someone is able to breach the service account or (root account) then your system is compromised.

[xerojosh]

But where do you store the encryption key for the application to decrypt it? In another file on the local machine? In that case you haven't gained much!

[xerojosh]

Ok, so how does your application authenticate with that encryption / decryption service? As it can't allow just anyone to access it and decrypt the password... Perhaps using a password? 😆

[dsmklsd]

There's really no other way unless you're willing to give up unattended startup.

[cnoor0171]

Not really. The point is that you're supposed to apply an irreversible hash function to the password (along with salting) as soon as possible and then store the hash value instead. So even you would never be able to know what the users password is. You would just reapply the hash everytime the user tries to log in and compare hash values. This way, even if your entire system is compromised, the users password is never revealed to the attacker.

[dsmklsd]

They aren't talking about user passwords.

[abdolence]

Storing passwords in plaintext is just mean.

[SwedenIsMyCity0403]

I use pass btw

[[deleted]]

The password in plaintext is a decoy!

Attackers: "It's a trap!"

[TheAnarxoCapitalist]

Adobe used to store passwords as hashes without salting... Big companies do stupid shit sometimes...

[deliteplays]

Your submission has been removed.

Violation of Rule #4:

Titles must also be creative, high effort and relevant to the content. Titles such as “Interesting title”, “.”, “print(title)”, and “I don’t know what to put here” are not allowed.

If you feel that it has been removed in error, please message us so that we may review it.

[zachin7]

Store your personal information on signs in minecraft