patrick.net

@Patrick - I agree. Up it to 18 characters. Nobody memorizes their password here anyhow - they just have the browser remember it.

And the passwords here are 6 characters long. I know because the power off is at my place today and I sent my password to my phone so I didn't have to update it on my browser when I got home.

12 is now considered the minimum length.

Keep in mind the table shows how fast they can find a hash collision matching your hashed password, computing via a desktop gpu. That means they must first exploit the site to get access to the hashed passwords stored in the db. If they can perform such an exploit, there's a decent chance they don't even need to bother finding your patnet password, as they can probably just access or do whatever they need directly via exploit at that point. But there's a small chance the exploit only allows them to read the hashes, and not necessarily do other things, in which case they may still be interested in finding someone's password.

6 chars is pretty short, but not unreasonable imo given that theyre very random and do not contain dictionary words. If I recall it's lowercase ascii letters and numbers, so 26 + 10 = 36 chars. 36^6 = 2,176,782,336 possible passwords.

They could try to brute force login via trying every possible password. Let's assume they can try 100 passwords per second without patrick noticing the surge in webserver load. ~2 billion passwords / 100 per second = ~21,176,823 seconds, or ~251 days. Of course they can get lucky and guess correctly on the first try, but on average you'd expect it to take 125 days per password to guess.

That's actually not too insecure, considering this site is a relatively low-value hack target.

Throttling how many logins per second the site allows is a cheap and ez way to up the cost to brute force a password via login attempts significantly, without increasing password length. Limiting to 100 global logins per 10 min would never hurt real users, but would well thwart brute force attacks.

Or going to just 8 char passwords from 6 would take you from 251 days to 326,517 days, which is nice as it would eliminate a sneaky hacker who maybe keeps the attempts per second low, helping to evade detection, but keeps it up for a year or 2 in order to crack patricks password.

I'm guessing patrick used 6 chars to make it easy to type the password in cases when you cant easily copy-paste (ie phone vs desktop).

Hircus says

I'm guessing patrick used 6 chars to make it easy to type the password in cases when you cant easily copy-paste (ie phone vs desktop).

Well.... Personally, I'm not religious about this and perhaps you're right, it's not really that important. This isn't a high value target site, AND, really if somebody got the password, what can they really do than say a bunch of bullshit you didn't? You could just have that deleted.

Ya I think the possible damage is low.

Maybe an angry leftist doesnt like someone's speech, and so cracks their password so they can login and see what their email address is, in hopes of linking to their real life identity (especially someone who discloses their wealth frequently). Or they login as someone, posing as them, then scamming their friends on this site who trust that account. Patricks account is particularly vulnerable to that I'd say.

Hircus says

That means they must first exploit the site to get access to the hashed passwords stored in the db. If they can perform such an exploit, there's a decent chance they don't even need to bother finding your patnet password, as they can probably just access or do whatever they need directly via exploit at that point.

Exactly.

I really hate websites that force all sorts of complexity in passwords, but the really don't need to have accounts at all (it's just for contact information harvesting) or the site data isn't all that important, or the likely users are easy targets for phishing.

As a related security pet peeve of mine: websites that thwart browser auto-fill information. The browser is very much more careful to check the domain and certificate of the website before entering that information, greatly reducing the chances of a user being directed to a fake site that creates a man-in-the-middle breech. Also, on sites that thwart auto-fill, I'm more likely to use a simple password.

SunnyvaleCA says

As a related security pet peeve of mine: websites that thwart browser auto-fill information. The browser is very much more careful to check the domain and certificate of the website before entering that information, greatly reducing the chances of a user being directed to a fake site that creates a man-in-the-middle breech.

Here, I want to bitch and moan about passwords and security on websites.

A password should be salted with the public key of the certificate when you send it, so what you should be sending is:

SHA256SUM [ (public key) + SHA256SUM (password) ]

You'd have to send SHA256SUM (password) to the site ONCE, but once you do that there should be additional salt. If the website is a forgery, they wouldn't be able to recover your password so phishing goes away. It would be easy to build this into the HTML standard. Passwords are already handled uniquely, when you use PROPER passwords - they aren't sent in the clear, they are hashed first then sent to the website. Hardly any website does this though, including I think this one.

With this method you wouldn't be able to log in unless you are using HTTPS - but that's the way it ought to be. Even I run HTTPS on my server - I use Let's Encrypt, it's simple enough.

I read this a few years ago, so feel free to savage it. Essentially, the best passwords are phrases that are much longer than traditional passwords, and that don't require special characters, such as "How shall I compare thee to a summer's day? Thou art lovely and more temperate."

Since the text is non-random, it is more resistant to brute force algorithms.

stereotomy says

I read this a few years ago, so feel free to savage it. Essentially, the best passwords are phrases that are much longer than traditional passwords, and that don't require special characters, such as "How shall I compare thee to a summer's day? Thou art lovely and more temperate."

Since the text is non-random, it is more resistant to brute force algorithms.

Yep:

"HeDidntWalkStraight,"
"KindaSideToSide,"
"HeSaidIsThisChicken,"
"KentuckyFried?"

Or

"ManISoHungry!"
"HowMuchForARib?"
"OneOrderOfRibs!"
"NoMan,JustOneRib!"

Lyrics or movie blurbs are the best. Throw in a symbol or number and capitalize Each Word for maximum effect.

I live and breath cybersecurity. It's my job.

I agree with using a password manager. DO NOT use your browser. Keepass is fine but you'll lose it all if you lose the device it's installed on. Cloud tools are much more convenient but I understand the angst to having it all in someone else's cloud. Having said that, I use Lastpass because they've been hacked before and the vault hashes weren't stolen, although authentication hashes were. Even if vault hashes were stolen, they will never be cracked (per the table above) as long as you set long, random passwords--I default to 20 characters and full complexity. Additionally, Lastpass cannot access your clear text passwords because your master vault password, which only you should know, is what applies the hashing algo to your passwords. So, as long as you keep your vault password safe, set it to a long passphrase, enable 2FA, then a hacker can only gain access if you screw up.

porkchopexpress says

I live and breath cybersecurity. It's my job.

Then riddle me this:

Why don't webservers just have different salt when a password is requested and store everything has a hash of the salt+password.

In this way, no password would ever be stored in the clear, even when it's setup and having a website compromised wouldn't matter. Why isn't this just standard for web browsers?

SunnyvaleCA says

I really hate websites that force all sorts of complexity in passwords

I've never worked at a single company that really understand password security. They all force these bullshit rules on you, and the worst are the ones that make you periodically change your password, and it cannot match last n passwords used. Because of stupidity like this my work passwords are always the weakest ones, too many useless rules.

porkchopexpress says

Keepass is fine but you'll lose it all if you lose the device it's installed on.

That's why you have redundancy! My vault is backed up to my home server, and uses a usb key rather than a password to unlock. So fuck the rubber hose, if I smash my USB's, no one's getting those passwords.

stereotomy says

Essentially, the best passwords are phrases that are much longer than traditional passwords, and that don't require special characters, such as "How shall I compare thee to a summer's day? Thou art lovely and more temperate."

Looking at the chart above, if it's long enough, will never be cracked outside of social hacking. If it's not generated by Keepass, my passwords are 30 characters and up.

I'm sure our fearless leader stores our password hashes salted with a Cryptographically Secure Pseudo-Random Number Generator.

Hircus says

Keep in mind the table shows how fast they can find a hash collision matching your hashed password, computing via a desktop gpu.

The last time I heard six was secure was early 2000's. That's why almost all websites upped requirement to eight a few years back. My concern is not a random hater, it's the government.

So a guy can use a computer to crack my password and username to impersonate me and post more bullshit than I do?

Impossible, nobody can duplicate my writing style.

How much computing power does he need to guess both my username and then my password?

NuttBoxer says

Hircus says

Keep in mind the table shows how fast they can find a hash collision matching your hashed password, computing via a desktop gpu.

The last time I heard six was secure was early 2000's. That's why almost all websites upped requirement to eight a few years back. My concern is not a random hater, it's the government.

The govt is still limited by how many login attempts per second patricks webserver+mysql server will support, just like any other hacker is.

richwicks says

porkchopexpress says

I live and breath cybersecurity. It's my job.

Then riddle me this:

Why don't webservers just have different salt when a password is requested and store everything has a hash of the salt+password.

In this way, no password would ever be stored in the clear, even when it's setup and having a website compromised wouldn't matter. Why isn't this just standard for web browsers?

You still need to store the salt though. And generally, I see most systems store the salt in the same table row in the db as the password. So, if the hacker is able to exploit to get the hash, they will likely get the salt too. I suppose you could store the salt in a different table and/or db and hope that an exploit that accesses the password table would not necessarily also access the salt table, but I'm not sure how well that would protect in actual practice given that the webserver still needs access to both in order to perform a login.

AFAIK, using a unique salt per password mainly prevents use of rainbow tables to speed up the discovery of hash collisions. If someone is actually trying to dynamically brute force compute the hash collision (like the original post), the salt per password offers no major benefit that I can think of. But, using a salt per password is considered good practice, and is used in industry, because rainbow tables are very effective, so defending against them is a good idea.

NuttBoxer says

SunnyvaleCA says

I really hate websites that force all sorts of complexity in passwords

I've never worked at a single company that really understand password security. They all force these bullshit rules on you, and the worst are the ones that make you periodically change your password, and it cannot match last n passwords used. Because of stupidity like this my work passwords are always the weakest ones, too many useless rules.

But, there's more to security than just the strength of a password.

Password policies aren't really aimed at people who already use strong passwords and good password mgmt practices. Theyre aimed at raising the lowest common denominator and preventing entire classes of certain security attacks from being possible - basically preventing the vast majority of users who know nothing of security from choosing poor passwords. But also, in my experience, many "expert" users dont know nearly as much about security as they think they do, and so they benefit from these policies too.

Forcing users to change passwords every 90 or so days is a pretty good practice. If your password gets compromised, then after 90 days they will no longer have the password (because you changed it). Of course, often the hacker only needs 1 day to do their dirt, but there's many scenarios where the person who acquires the other user's password doesnt realize it for many months. Imagine a password that ends up in a log somewhere, and a sysadmin happens upon it a few months later. Or a disgruntled employee who leaves the company, and is now willing to sell the password that they never change. There's many similar scenarios. Changing passwords factually helps in many of these scenarios, and helps even the very strongest passwords.

Also, users hate to change passwords, and when you force them, they will resist, and will try to switch back and forth between 2 easy to remember passwords, if allowed. Ie p@ssword1 and p@assword2. This defeats many of the benefits offered by changing passwords regularly, because the same password gets reused for half of each year, forever. So, preventing users from reusing passwords within the past 8-24 passwords helps prevent users from shooting themselves in the foot by defeating the policy that requires you to change your password regularly.

Microsoft Active Directory is used by tons of companies as a userid/password database, and their standard password policy includes this stuff, and more. So a lot of companies get their password policy from using that, although I've seen very similar policies in other products, as they tend to be widely considered good policy.

Hircus says

Imagine a password that ends up in a log somewhere, and a sysadmin happens upon it a few months later. Or a disgruntled employee who leaves the company, and is now willing to sell the password that they never change.

In these two examples log santization and a policy that immediately locks an ex-employee out are better practices, and really essential to running a secure business. Forced password update is not a good fallback for either of these.

Hircus says

Also, users hate to change passwords, and when you force them, they will resist, and will try to switch back and forth between 2 easy to remember passwords, if allowed. Ie p@ssword1 and p@assword2.

So this is an issue with password complexity, and again, forcing no re-use is not an excuse for poor complexity requirements. Employees would be fine with one password per required login the entirety of their employment. Just make it long enough, whatever characters they want, but set a minimum length. And make them use a corporate password manager to create and store all their passwords in.

Also, 2FA is complete bullshit. It's implemented as a way to issue in a global Id and tracking system, and has zero security applications what-so-ever. It expands attack surface to personal devices that have a plethora of security vulnerabilities. And as mentioned in the above examples, it's only utility is in lieu of enforcing longer passwords, and the use of password managers. Just implement a minimum character length, no re-use across different accounts, and storage in a password manager, and all the rest of this security theater goes away.

I store almost all my passwords in a file on my phone. It’s buried a bit in an app, and would require some searching around to find it, but there are like 45 passwords on there for various services and apps I use at least occasionally. No way I am remembering them all. My system isn’t foolproof, but you’d need to first access my password protected phone to get my other passwords.

NuttBoxer says

porkchopexpress says

Keepass is fine but you'll lose it all if you lose the device it's installed on.

That's why you have redundancy! My vault is backed up to my home server, and uses a usb key rather than a password to unlock. So fuck the rubber hose, if I smash my USB's, no one's getting those passwords.

Agreed if you're hardcore. Most people want convenience and aren't willing to go that far, so that's why Lastpass works great because people will actually use it and have the backup data built in.

richwicks says

porkchopexpress says

I live and breath cybersecurity. It's my job.

Then riddle me this:

Why don't webservers just have different salt when a password is requested and store everything has a hash of the salt+password.

In this way, no password would ever be stored in the clear, even when it's setup and having a website compromised wouldn't matter. Why isn't this just standard for web browsers?

I suppose you could do that but it sounds like a complicated architecture. If you use a solid hashing algo with long passwords, it won't matter because they can't be cracked. Of course none of this matters if you're phished or you allow "pass the hash" attacks in your environment.

richwicks says

@Patrick - I agree. Up it to 18 characters. Nobody memorizes their password here anyhow - they just have the browser remember it.

And the passwords here are 6 characters long. I know because the power off is at my place today and I sent my password to my phone so I didn't have to update it on my browser when I got home.

12 is now considered the minimum length.

i don’t know mine, but i don’t log out either because i don’t think ill know how to login again without registering again. i kind of miss picking a password

richwicks says

12 is now considered the minimum length.

My wife says the same thing

NuttBoxer says

Hircus says

Imagine a password that ends up in a log somewhere, and a sysadmin happens upon it a few months later. Or a disgruntled employee who leaves the company, and is now willing to sell the password that they never change.

In these two examples log santization and a policy that immediately locks an ex-employee out are better practices, and really essential to running a secure business. Forced password update is not a good fallback for either of these.

Strawman argument. I never said the policy was meant to replace or be used in lieu of any security measures or practices - it is meant to augment, as things will inevitably slip through the cracks, and the policy is there as a safety net, helping in very legitimate ways for certain scenarios.

How could you identify passwords in logfiles with certainty, so as to "sanitize" the logfile? It's unrealistic, especially when passwords arent even supposed to be in the logfile in the first place and you dont anticipate it. For example, a broken html form, which ends up submitting via GET instead of POST, putting the password into the url, which puts the password into a webserver url logfile. The broken form need not even be the fault of the web page author - the browser could be at fault, or a browser extension, causing the end user to not realize their password was just sent to a logfile somewhere, possibly in router and proxy logs too. How could you realistically prevent all that? There's countless other possibilities just like this contrived example, many of them being rare, but there's many of them, making directly addressing them often difficult, expensive, or impossible. Yet the simple policy mitigates many of them, while still allowing you to directly address things where you see fit.

Regarding locking out the userid of an employee who leaves the company - again, there's more scenarios you haven't considered. What if it's not their userid? (ie a db connection password, or a password to some other infrastructure in the company). Many companies forbid password sharing between employees for many good reasons (this being one of them), but inevitably, some userids will still get shared because sometimes its unrealistic or impossible to have more than userid for some systems or software.

NuttBoxer says

So this is an issue with password complexity

No, it is not. Yet another scenario you have not considered. If the password is compromised, possibly not yet realized, it doesn't matter if the password is 5 billion characters long. Making it longer and stronger wont help, because someone else has (or will soon have) the password, and nobody realizes it has been compromised, and so would have no reason to change the password. The policy which forces people to change all passwords periodically might save the day here, whereas additional complexity is useless.

What if the password is for a service in the company intranet? Unless the hacker gets intranet access, their knowledge of the password wont be of any use to them. But, what they usually do is compromise the laptop of an employee who has intranet/vpn access, and then they use their laptop as a jumpbox, giving them intranet access, and now they can use that password. Tell me, what is better - letting the hacker have forever to gain intranet access and use the pw, or making it so they have at most 90 before someone changes the pw? Sometimes exploiting an employee laptop takes time, especially since they need to usually make many attempts at social engineering, which takes time to get lucky and have it work. Again, adding additional complexity doesnt help you in the slightest here.

NuttBoxer says

Also, 2FA is complete bullshit. ... and has zero security applications what-so-ever.

Zero?

Youre just a shit poster. You tried to make this same frivolous 2fa argument in that other thread where I shot down your BS arguments. Same thing in that thread - a bunch of scenarios you dont/wont consider, and so you falsely conclude, and then when they're pointed out to you, you advance strawman arguments since you cant debate the actual substance and logic of the post. I suspect you will keep dancing around, advancing more strawman arguments like you did in this thread, as well as in the other thread. You dont fool me for a second with this BS.

Hircus says

No, it is not. Yet another scenario you have not considered. If the password is compromised, possibly not yet realized, it doesn't matter if the password is 5 billion characters long.

Passwords are stored with "salt" on any system worth a damn.

If your password is : "HiThere!5%"
It will be stored with something like this SHA256SUM(rich_wicksHiThere!5%SOME_SALT)

Because you're using a hash, it's POSSIBLE that you could find another password that results in the same SHA256SUM - but it doesn't do you much good. You cracked the password on that one system, but "SOME_SALT" will be different on another machine so the hash will be different.

Passwords haven't been stored in the clear for at least 30 years by anybody competent. The file in /etc/password used to be able to be downloaded on Unix mainframes back in 1990 - we'd grab the file, and start trying to hack it by guessing passwords with a program. People would use very weak passwords, like dictionary words, or phrases, etc - people tend to think alike. We'd get about 10% of them cracked after a machine spent a couple days working on it.

They used to use bcrypt which wasn't NEARLY as good as SHA256SUM, or SHA1 for that matter.

Really, I think the salt should change on each login, and that's possible to do - this prevents a replay attack.

No security expurt, but I've had to deal with it a little bit.

With my passwords, I string a bunch of words together that would never be strung together - something like ILampshadeRunGrassAttackMine

That combination of words wouldn't be able to be guessed, and if you do this: ILampshade?RunGrass5AttackMine

That's impossible - with brute force anyhow.

People are a little be over-paranoid with their passwords in my opinion. Your password on your personal machine only prevents your wife or kid from accessing it. If you give me access to your machine - like let me have your laptop for a couple hours, I'd just duplicate your disk. This is what happened to Hunter Biden. This is trivially prevented by encrypting the file system - yet doing that has it's own set of issues - like you could do this with Linux, but accessing the drive if you had a problem with your OS could become impossible.

I think security is intentionally made weak. Why is email still sent in the clear instead of encrypted by default? Simple, the government doesn't want to give you privacy. This is EASY TO DO, but nobody does it - not even corporations. Isn't that odd?

richwicks says

Passwords are stored with "salt" on any system worth a damn.

The key word here is its "stored" hashed and salted. But the password is still typed or entered as plain text, and often transmitted plain text as well (albeit usually in an encrypted tls/ssl tunnel) allowing the plain text pw to still be compromised. Keyloggers, reading memory, user accidents/mistakes, software bugs, etc... are still possibilities to compromise the actual password.


richwicks says

Really, I think the salt should change on each login, and that's possible to do - this prevents a replay attack.

I assume you mean the webserver should generate a random salt per login form display, and the client will use that to salt the users pw, hash it, and then send the hash back to the server to authenticate? I agree it has some security benefits, but I think doing so would necessitate some undesirable changes.

You'd need to store the password on the server either:
1) plain text (or encrypted on the server, but w/ the login webserver having access to the decryption key)
2) hashed without any salt
3) hashed with a salt per-password

If you did #3, then you would need to send that per-password salt to the client, in addition to the random per-login salt, on each login form display.

Thinking about it more, while I don't like sending the per-password salt to the client, I think the trade off is well worth it, and so feel #3 is preferable to having the client send the actual password to the server the way most websites currently do it. I don't really like #1 or #2.

Can you think of another way to accomplish it besides those 3?

Who cares about the password. 2-step all the way. Pain in the ass, but you ain't logging into to my account without texting me or me inputting the random generated code every 30 seconds to log in. All other accounts I give zero shits about. If someone wants to post for me here, have at it. All financial or anything with personal information is legit on lockdown. Not even the best hacker could get to it without kidnapping me.

porkchopexpress says

Agreed if you're hardcore. Most people want convenience and aren't willing to go that far, so that's why Lastpass works great because people will actually use it and have the backup data built in.

For sure. I put my wife on bitwarden, no way she'll use local files. Although she still doesn't have a single password stored on it. I told her she has to unlock the app first for it to prompt her, but she never does...

Hircus says

How could you identify passwords in logfiles with certainty, so as to "sanitize" the logfile?

Dude, this is literally a CISA requirement. Had to test this for a former employer, and had to implement it to keep sensitive creds from showing up in our test logs. That you would even say this tells me you don't have the experience to weigh in here.

WookieMan says

but you ain't logging into to my account without texting me or me inputting the random generated code every 30 seconds to log in.

Look into the concept of reducing your attack surface. Personal cellphones are fucking fat juicy target, and a huge liability to security, not an asset.

Try browsing the security subs on reddit. 2FA is the lazy man's security, and absolutely is being leveraged to create a digital ID to track everything you fucking do. Have we learned nothing from the last two years?

NuttBoxer says

Also, 2FA is complete bullshit. It's implemented as a way to issue in a global Id and tracking system, and has zero security applications what-so-ever.

Are you referring to using a text message as a second form of authentication? Not all 2FA is the same!

How about those 2FA systems that use a "random" number that changes every 10 seconds that you type in with the password when logging in? Those seem to thwart a bunch of potential problems. I've used those systems with a dedicated dongle a while back and, currently, am using VIP access on my phone and watch.

NuttBoxer says

Try browsing the security subs on reddit. 2FA is the lazy man's security, and absolutely is being leveraged to create a digital ID to track everything you fucking do. Have we learned nothing from the last two years?

The minute you create an account you're a known commodity. There's little you can do. An employee with the company can literally see any data they want. 2FA for sure protects you from outside hacks. There's NOTHING you can do to stop insiders from looking at your info. Nothing.

There's always a chance of being fired (not me), but I could get you investment accounts from JP Morgan in minutes if I wanted. We're talking 10 figure accounts. I could steal funds. There's always one person that knows your account info, always. You're not secure. Circle jerking about it is a waste of time. Live your life. Use CC's or cash. Never debit. 2FA on financials, and yes, it 100% works. Haven't ever had a hack on my CC's with close to 20 cards and a couple hundred thousand in credit lines. I'm a perfect target. Nothing.

This obsession with privacy makes me think you're doing illegal things. There's really no reason to have such a hard on for it. Time is money and you're wasting it on something that is a net negative to your bottom line.... being paranoid.

Shaman says

My system isn’t foolproof, but you’d need to first access my password protected phone to get my other passwords.

Bad joke.

OK, I'm back home now.

I could let people pick their own password, but it's generally a bad idea because some of them will use their bank password or something else important.

The time to crack assumes you get immediate retries, but it's easy to put in a small delay after each wrong guess, which greatly ups the time to guess.

I don't even know what my patnet password is. I just do the email reset and click through and I'm logged in.

Works great! Pre-pandemic I did it frequently with one hand while I had a sammich in the other on my lunch breaks. I'd lose login at night when I used my home PC to log in so had to redo at lunch.

These days I eat at home and watch shiite on my roku instead.

@NuttBoxer Your wish has been granted. The profile page now has a place to put in a new password.

https://patrick.net/edit_profile

Let me know if I fucked anything up and it's stopping you from logging in. Email p@patrick.net in that case.

Hircus says

The key word here is its "stored" hashed and salted. But the password is still typed or entered as plain text, and often transmitted plain text as well (albeit usually in an encrypted tls/ssl tunnel) allowing the plain text pw to still be compromised.

My first reaction to reading that is "you don't know what the fuck you're talking about".

But you're right. I was certain that Apache's dialogue box accepted a hashed password that was generated on the client. It doesn't, the password is sent in the clear - I just checked.

And then upon further thought, you can't just produce the same salted hash either, because that would allow a playback attack which you can do anyhow if there was a man in the middle listening if they somehow broke TLS. Now I have a problem to work on. There's got to be a better solution.

In any case, a malicious website would be able to record the password in the clear as it currently stands. I think having a server send you salt, and then you sending the salt hashed with your hashed password would be better. Nothing would stop a keylogger, but the server wouldn't be able to see your password ever. Seems like how it currently works with webservers is the worst possible way of doing it.

SunnyvaleCA says

Not all 2FA is the same!

Regardless of the method, the end result is the same. Expanded attack surface that offers no benefit over a secure password. I've used a dongle in the past, and if a company is going to insist on 2FA, that's the method they should use. A cellphone as the secondary device is overkill, and exposes the company to way too many attack vectors.