patrick.net

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.

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?