patrick.net

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.

Fortwaynemobile says

i kind of miss picking a password

@Fortwaynemobile You can now pick a password on patrick.net.

See https://patrick.net/edit_profile

WookieMan says

There's NOTHING you can do to stop insiders from looking at your info. Nothing.

My company didn't know my real name until I signed my offer letter. They will never know my home IP. The only info they get is work related, I don't use my work laptop for personal stuff, not even to browse.

WookieMan says

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.

Despite never using 2FA, the only hack I've ever suffered was a XSS attack on a site where I bought pool supplies. And guess what, 2FA wouldn't have saved me in that case, and cross-site scripting is the most common form of attack, always near or at the top on the OWASP top 10. Haven't ever had that happen since, but I use pre-paid cards for almost all online purchases now.

WookieMan says

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.

You sound like the government. They're the only ones I know who hate privacy so much they lie by telling us we don't need it. Yet they build walls around their houses, keep everything in trusts, and send all their IM's using Signal. Maybe you should stop listening to what they say and start looking at what they do.

I did have to invest some time in the beginning, learning how to protect myself and my family, but now it's second nature. You do believe in physical security right? Locked doors, and guns? I just extend that belief to the point where I almost don't need either. Because if you can't find me, you certainly can't open my door, or force me to draw my gun. Just because the world doesn't understand the importance of locking their digital front door, doesn't mean I have to leave mine wide open..

NuttBoxer says

I use pre-paid cards for almost all online purchases now.

@NuttBoxer where do you get these pre-paid cards? What is the cost to use them?

Patrick says

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

Thanks Patrick! Upped my complexity with some uppercase and special characters, and length is now 20. And since I use a password manager, patnet gets a unique password all to itself.

For this reason I hardly rotate my passwords anymore, since a hack will only give you that one account.

Patrick says

where do you get these pre-paid cards? What is the cost to use them?

I buy them at my local supermarket chain, here it's Albertsons. Cost is $5.95 to activate, so I get the max limit $500. Anything where I can remain anonymous gets paid with them, the few where I have to disclose some personal info get paid with my debit.

richwicks says

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.

There's other auth methods commonly used, and some of them also send a plain text password. For example, the method used by this very site is by far the most popular method in use on the web - and it just uses a basic html form which submits the username and password as plain text.

richwicks says

Apache's dialogue box

Apache is just an http webserver, and can be used in many different ways to support logins. It doesnt have its own dialogue box - thats the web browser making an "http authentication" box in response to seeing an http header in the the webserver response. Historically, the most common type of "http authentication" is "basic http authentication", which is probably what you tested, as it sends the credentials to the server as plain text.

There's also "http digest authentication", which uses hashing to avoid replay attacks, as well as to prevent transmitting the password as plain text. But nobody really uses it anymore. Digest was popular before ssl became ubiquitous, and people used it because the easy alternatives (basic auth or html forms) transmit the password as plain text, which is horrible when not using ssl. But now that everyone DOES use ssl, most sites have rolled their own login mechanism via an html form as patrick did, and some sites still use http basic, especially for REST apis.

The big problem with digest auth, which is a form of hashing on the client thats done using a 1-time-use salt, is that the server needs to know the actual password, or something equivalent to the actual password. Storing the password hashed and salted on the server wont work with digest auth. well, technically they do store it hashed and salted, but the problem is this hash ends up functioning like a password if an attacker can get it - so its "equivalent" to storing a password in most regards. I already mentioned that you would need to use one of those 3 scenarios I laid out to accomplish client side hashing with a 1 time use salt, and digest auth is an implementation of that which chose one of those 3.

btw in my previous post I stated I thought #3 was possible and would work well, but I take that back. It would work, but I feel the stored hash would function as a password, if disclosed, just like w/ digest auth.

So ya, most sites are sending the username and password as plain text with SSL/TLS, or some use more elaborate stuff like SSO/OAuth. They could use digest, but it's probably a step backwards at this point. Due to SSL, it's already tough to read the password in transit between the browser to the webserver, so sending a hash, while beneficial, is probably not a large benefit. I don't think its worth the cost of storing unhashed passwords (or something equivalent to a pw) on the server in order to make use of digest.

Industry and especially enterprises are quickly moving towards oauth, as one of its many benefits is that the user doesnt need to type credentials into the web site - the users browser is redirected to the origin identity provider website, and they login there, then they get redirected back to the specific web site, and are then logged in without ever sharing a password with that individual site. Of course the origin identity provider receives a password, but its better that 1 site with a focus on doing secure logins gets the password, than many sites. There's lots of pros and cons to using something like oauth. A nice oauth + SSO benefit is it makes 2fa less painfull - you can 2fa into the identity provider 1 time per day, and then all the other websites just share your login session without necessarily requiring you to 2fa again for each site.

NuttBoxer says

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.

First it was strawman arguments.

Now its ad hominem. You try to discredit me instead of debating my point (because you cant identify passwords in logfiles with certainty).

Hircus says

First it was strawman arguments.

Now its ad hominem. You try to discredit me instead of debating my point (because you cant identify passwords in logfiles with certainty).

Just because you don't understand the argument, doesn't make it invalid or insulting. It just means you're in over your head, so maybe try a little humility. Masking creds is so common, rather than asking me for my personal experience, you can easily find a hundred examples online. But yes, I did mask sensitive creds, and I will again. Logs are programmed to detail specific data events, they're not random dumps of meaningless combinations of words. All you have to do is know the pattern that precedes the string you want to obfuscate.

But I think I'm wasting my time explaining this, as you don't give a fuck. You're too busy being arrogant.

porkchopexpress says

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

@porkchopexpress

Ah - found you. Besides OpenSSL, what do you suggest for a crypto library? I'm looking for AES256 and ECC public/private keypairs. I'm playing with the NaCL library:

https://libsodium.gitbook.io/doc/?source=patrick.net

But I'm running into an issue that the public/private keypairs it generates for different things (Diffie–Hellman versus digital signatures for example) I have to generate a completely new keypair rather than being able to reuse them. Got another library to suggest?

NuttBoxer says

Just because you don't understand the argument, doesn't make it invalid or insulting. It just means you're in over your head, so maybe try a little humility. Masking creds is so common, rather than asking me for my personal experience, you can easily find a hundred examples online. But yes, I did mask sensitive creds, and I will again. Logs are programmed to detail specific data events, they're not random dumps of meaningless combinations of words. All you have to do is know the pattern that precedes the string you want to obfuscate.

-You said the policy of rotating passwords was useless.
-I cited one of many examples where the policy is useful (when your password is disclosed, maybe accidentally). If you understand logic, a single useful example invalidates the "useless" claim. Plus, there's much more than just one example - you just dont understand them.

-I even cited an example how this could happen (pw accidentally ends up in arbitrary logfile). Not that I needed to cite a specific example, because citing the general category of password disclosure is sufficient to invalidate your "it is useless" argument.
-You said logfile sanitation would be a better defense than pw rotation.

The problem with that is you kinda need the "logfile sanitation" method to work for all possible log formats (or at least most popular formats in actual use) in order for that argument to even have a *chance*, because the pw rotation policy surely works for all logfile formats, and it also helps defend against many other password disclosure scenarios besides "passwords in logfiles".

I even gave an example of how a password can end up in a url, which of course means it will end up in an a webserver access logfile. A typical web server access log will log the url and query string. So if the pw ends up in a url, it will be in the logfile. Query string parameters are expected to be in the logfile, and the parameter names and values are quite varied from log entry to log entry, and so are their orders. You will not know which params and values are be expected (unless this is a trivial application), nor will you know where a password could be. Typical nginx webserver access log entry:

66.249.65.159 - - [06/Nov/2014:19:10:38 +0600] "GET /news/foo.html?param1=val1&Param2=val2&p=I_AM_A_PASSWORD&Param4=val4 HTTP/1.1" 404 177 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

To "identify passwords in logfiles with certainty" means your sanitization method should always work, and not miss passwords sometimes (and ideally, not strip out false positives either). Log formats are so varied, and you cannot rely on the password being in a certain parameter name, nor could you depend on just "stripping out strings that look like passwords" because some passwords are indistinguishable from other strings that are expected to be present. If you miss some passwords, then you are not identifying them withcertainty- you are missing some.

NuttBoxer says

But I think I'm wasting my time explaining this, as you don't give a fuck. You're too busy being arrogant.

Oh, the irony of you saying that. You've been schooled over and over again, resorting to subterfuge to try "be right" about something. And you still keep grasping onto your faulty positions, such as your odd "2fa is 100% useless" bleat.

That chart is useless and not true in most cases. Passwords are not hacked instantly or in a time, it's tries!
And any decent security system should detect the wrong password has been put in wrong after short amount of tries. 3 to 5 tops!
If a security depends on the users doing their job for them, by coming up with passwords they can't remember and will likely forget, then they just write them down to make the job for Boris the Russian hacker's job easier. Sasha his Russian girlfriend cleans your office on Tuesdays the Thursdays, she looks under every keyboard and takes pictures of every post it note with a password on it. That is how Boris hacks computers "Instantly".

Tenpoundbass says

And any decent security system should detect the wrong password has been put in wrong after short amount of tries. 3 to 5 tops!

The assumption you must ALWAYS make is that the attacker has the encrypted password file and the algorithms for it.

That's worst case - you always plan for worst case.

richwicks says

The assumption you must ALWAYS make is that the attacker has the encrypted password file and the algorithms for it.

That's worst case - you always plan for worst case.

To my knowledge not one single major Enterprise hack, or malware, trojan or encryption has been performed because a hacker cracked or guessed the admin password or of some rando user. It's most always from someone in the enterprise opening a spoof or phishing email.
The whole change your password just adds more complexity that gives the "Security" contractors job security. The amount of energy over hassling users over passwords and the lost productivity over it, cost the Enterprise more than they gain.

H@rvey123 is just as good of a password, as some crazy complex password with numbers and characters that has to be over 12 characters. With proper protocols and policies in place, how weak the password is, should be irrelevant as long as it isn't a stupid password like abc123 or password123. After the 3rd try your account should be locked. Period!

St@pWith1! these kinds of passwords.

IdLikeToBeUnderTheSea! instead. In an Octopus' Garden easy.

We were habituated to Hrd2ReCl but LandmineHasTakenMySight Or HerNameWasLolaSheWasAShowgirl Or ShineOnYouCrazyDiamond is sure easier to remember and faster to type and better.

AmericanKulak says

St@pWith1! these kinds of passwords.

IdLikeToBeUnderTheSea! instead. In an Octopus' Garden easy.

We were habituated to Hrd2ReCl but LandmineHasTakenMySight Or HerNameWasLolaSheWasAShowgirl Or ShineOnYouCrazyDiamond is sure easier to remember and faster to type and better.

I'd caution you with phrases that are well known.

EatAnAppleOrABear

That's never been written before, and will never be written again.

AmericanKulak says

ShineOnYouCrazyDiamond is sure easier to remember and faster to type and better.

Except for the Ahole IT managers that demand a Strong password. Using so many special characters and numbers.

The worse is autogenerated passwords and you don't have easy access to change it.
bm9XjoK#3nMG0cV0
This was a real password I had to use at one time. Which I always copied and pasted into the password box. I bet that's easy to capture for a hacker, than figuring out the complex password.

My point is the more complex they make passwords, then the lazier the user will be to have that impossible password handy, and the easier it will be for the baddies to retrieve it for the users actions of storing it on a sticky note, or pasting the password from a file on their computer.

richwicks says

porkchopexpress says

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

@porkchopexpress

Ah - found you. Besides OpenSSL, what do you suggest for a crypto library? I'm looking for AES256 and ECC public/private keypairs. I'm playing with the NaCL library:

https://libsodium.gitbook.io/doc/?source=patrick.net

But I'm running into an issue that the public/private keypairs it generates for different things (Diffie–Hellman versus digital signatures for example) I have to generate a completely new keypair rather than being able to reuse them. Got another library to suggest?

This isn’t my deep area of expertise, but what implementation language are you using?

Libgcrypt or crypto++ could be other options

Tenpoundbass says

The worse is autogenerated passwords and you don't have easy access to change it.
bm9XjoK#3nMG0cV0
This was a real password I had to use at one time. Which I always copied and pasted into the password box. I bet that's easy to capture for a hacker, than figuring out the complex password.

My point is the more complex they make passwords, then the lazier the user will be to have that impossible password handy, and the easier it will be for the baddies to retrieve it for the users actions of storing it on a sticky note, or pasting the password from a file on their computer.

Agreed. Long passphrases for ones you have to remember such as a vault or network password, but random generated at least 16 (I do 20) characters in a password manager for everything else because you won’t have to remember them. If the target system uses a good hash algo, they’ll never get cracked.

@porkchopexpress If you have security advice for patrick.net, please let me know.

Please poke around and tell me if you can break in in any way.

I once saw a study about pass phrases, where 5 out of 20 people chose the same passphrase, and most all chose a common meme or catchphrase.
Because "LetsGoBrandon" is easier to remember than "BaloneyBlanketGearMuch" or some random joining of words they never put together before, and probably wont remember if they don't write it down.

porkchopexpress says

This isn’t my deep area of expertise, but what implementation language are you using?

Libgcrypt or crypto++ could be other options

I'm using C. Libsodium MIGHT be OK to use. It's a little strange as a library, but it's very simple to use. If I can just get a public/private keypair for both signatures AND doing Diffie Hellman I'm set. One thing I like about the library is that it's not GPL, it's not BSD, it's "free". The Tox IM protocol uses it.

Tox has severe problems with it though:

1) It's awful on data transfers. It's SO SLOW, and 1/2 the time, the file gets cancelled.
2) You cannot log into two devices on the same account at the same time.
3) Both users have to be online at the same time to send a message (not so bad really)
4) Video and Audio are built into the library
5) If I have a friend's ID, I cannot give it to a 3rd party so they can add them to their list
6) TERRIBLE API to code.

There's some genius ideas in it:

1) No need for a server - good and bad, in that it really sort of does, but just to connect the users.
2) P2P and E2E communication.
3) Complete IP address independence.

Patrick says

@porkchopexpress If you have security advice for patrick.net, please let me know.

Please poke around and tell me if you can break in in any way.

I just did a light scan and nothing too concerning showed up.


You also have some missing security headers:
Content-Security-Policy
X-Frame-Options
X-XSS-Protection
X-Content-Type-Options
Referrer-Policy
Strict-Transport-Security

You do expose some information such as Nginx 1.18.10 and JQuery 1.11.2, which a hacker could leverage but I'm not that worried about it.

Thanks @porkchopexpress

I plan to remove jquery anyway, but will make a note of the headers and hide the server name and version.

Tenpoundbass says

That chart is useless and not true in most cases. Passwords are not hacked instantly or in a time, it's tries!

Seems you've never heard of the re-authentication attack for wifi. I force all your devices off, then grab your WPA key when you log back in. From there I just run a dictionary against that key until I find a match, then I have your password. It's been a while since I took that security class, so apologies if some of my terms are the most accurate.

NuttBoxer says

Tenpoundbass says

That chart is useless and not true in most cases. Passwords are not hacked instantly or in a time, it's tries!

Seems you've never heard of the re-authentication attack for wifi. I force all your devices off, then grab your WPA key when you log back in.

Isn't the key sent over on AES after it key exchange is determined by Diffie - Hellman? I mean, we've had this shit around a LONG TIME as part of web page TLS security. I know RSA calculation is pretty expensive computationally, but ECC isn't.

Tenpoundbass says

My point is the more complex they make passwords, then the lazier the user will be to have that impossible password handy, and the easier it will be for the baddies to retrieve it for the users actions of storing it on a sticky note, or pasting the password from a file on their computer.

That's why companies need to have password manager subscriptions. Make it stupid simple for the users to create and save complex passwords without having to ever write them down or memorize them.

NuttBoxer says

That's why companies need to have password manager subscriptions. Make it stupid simple for the users to create and save complex passwords without having to ever write them down or memorize them/

@NuttBoxer

I have a patent idea that would work though, that wouldn't do that, and would be pretty damned secure. Would require some hardware, but it would be cheap and fairly easy to make.

I think one theme I keep seeing here is people assuming a hacker always targets a specific individual. Unless they are a high profile target, this never happens, and no one on patnet meets that criteria. What they will do get a list of users, setup a bot farm, and run a dictionary against every user in the list. The shorter the password, the less combinations they have to iterate through before getting to one that works. I honestly don't see any hackers targeting this site, except for government. And while you might not think that's a big deal, look at the attack on freedom of speech the last few years. Then look fascist regimes of the past or present. It's a big deal.

And yes, as pointed out, SW exploits and phishing attacks, and social engineering are the most common types of attacks. But the stronger your security practices are overall, the less chance you'll ever be targeted or compromised, including password length. I mean, as much as it's gotten poo-poo'd here, with justifiable examples, I've never ever heard a security person in personal conversation, conference, class, etc, say password length doesn't matter.

NuttBoxer says

What they will do get a list of users, setup a bot farm, and run a dictionary against every user in the list.

How does that work when after three tries the account is locked out?

HeadSet says

How does that work when after three tries the account is locked out?

THat's what I keep wanting to know.
I think this is just bullshit the Indian IT cabal that has America's computer infrastructure hostage with inept idiots running those IT shops. Like to spread to cover their incompetence and to support their failed IT best practices.

They want us to believe that hackers hack networks like you would see in 80's and 90's movies where the bad guy hackers would hack defense computer systems to steal the nuclear launch codes. Using a program that parses a long password list and tries every combination. That image is ingrained in our minds so we just take it for face value when they say bullshit like this.

Systems are compromised due to the impossible passwords and the constant password changing, dragging every computer user through stupid unnecessary steps because one of the network guys was looking at porn or downloading binaries and caught a nasty Trojan, or the Receptionist opened a phishing email.
Which would reflect very bad on the IT management for not having the network locked down that people could browse unsavory sites, or malware email could get through their mail filters. And you'll never prevent network intrusion when your users are forced to write their password down so they will remember it.
And changing your passwords at any weird time interval does absolutely dick all but create more opportunity to compromise your password.
The only time you should need to change your password is if you have reason to believe your password has been compromised or the password list has been breached.

FWIW I am using the exact same password I created for my very first Windows 95 machine and used to sign up for AOL in 1996.
It has never been compromised.

Tenpoundbass says

FWIW I am using the exact same password I created for my very first Windows 95 machine and used to sign up for AOL in 1996.
It has never been compromised.

AOL probably recorded the password in the clear, meaning it was compromised, however a password is pretty worthless with a Windows 95 machine - you can't do a remote login on it.

I've been using Linux as my main OS since Slackware 0.99 - 120 floppy disks, back in I think 1993. That can be compromised. I don't even use a recognizable username on my machine, much less a common password, and "root" is disabled by default. I don't even use a standard port. Try to crack my machine:

samoyed.dynu.net
or
75.31.75.102

I'm just pointing out that security is 99.999% not getting a phishing attack. You cannot attack my machine even if you go through all the CERT advisories.

HeadSet says

How does that work when after three tries the account is locked out?

Maybe not the best example, but the point is, the attack will be much broader than a single user, and weak password requirements mean less guesses before getting a match.

Tenpoundbass says

FWIW I am using the exact same password I created for my very first Windows 95 machine and used to sign up for AOL in 1996.
It has never been compromised.

I think most of us agree changing the password isn't as important as picking a good one to start with, and NOT re-using it. The only exceptions I can think of are Wifi, and your bank account. The bank isn't about someone guessing it, it's about a data breach where they scoop you up with everyone else, and you have a real risk of losing something(your next paycheck).

richwicks says

I'm just pointing out that security is 99.999% not getting a phishing attack.

So true. Over 90% of successful cyber attacks involve some sort of social engineering (e.g., phishing) because it works.

NuttBoxer says

HeadSet says

How does that work when after three tries the account is locked out?

Maybe not the best example, but the point is, the attack will be much broader than a single user, and weak password requirements mean less guesses before getting a match.

The assumption has to be worst case scenario.

Assume the encrypted salted hashed password file is available.

Of course a direct attack can be thwarted by adding 1 second between an attempt. Assume they have direct access, that they have bypassed the hardware and have direct access to all files. That's what you're dealing with when you're dealing with an intelligence agency and some traitorous fucking company like Amazon. Don't trust 3rd parties to help you, ANY 3rd party.

richwicks says

I don't even use a recognizable username on my machine, much less a common password, and "root" is disabled by default.

I disabled password logins entirely on my patrick.net machine. The only way in is the ssh key.