|
Is it possible to securely store someone’s past x passwords to prevent them from reusing an old password? The only way I’m thinking it’s somewhat possible would be to assign each user a randomized key (I’m not loving calling it a pepper) and storing it secured separately from the rest of their data, using it on each password before hashing, and then checking their new password against the old hashes by running it through the hash process with the key. Even then, though, there’s a problem. Figure out one of a person’s old passwords, you can figure out the key, then you have all of their past x passwords assuming you have access to the database. Unless you randomize the key every time they do a reset and store the last x keys as well in the same order, again in a separate location from the hashed passwords. I just ran across a password policy that forbids reusing your last 24(!) passwords, which made me wonder.
|
#
?
Jun 12, 2019 19:48
|
|
|
|
| # ? Apr 19, 2024 14:23 |
|
|
22 Eargesplitten posted:Is it possible to securely store someone’s past x passwords to prevent them from reusing an old password? The only way I’m thinking it’s somewhat possible would be to assign each user a randomized key (I’m not loving calling it a pepper) and storing it secured separately from the rest of their data, using it on each password before hashing, and then checking their new password against the old hashes by running it through the hash process with the key. Even then, though, there’s a problem. Figure out one of a person’s old passwords, you can figure out the key, then you have all of their past x passwords assuming you have access to the database. Unless you randomize the key every time they do a reset and store the last x keys as well in the same order, again in a separate location from the hashed passwords. I would just think they'd keep and compare your previous hashes. Your current password will exist in hashed form, I don't know why you'd go to extra effort to further secure past ones beyond how you store the current.
|
|
#
?
Jun 12, 2019 20:05
|
|
|
22 Eargesplitten posted:Is it possible to securely store someone’s past x passwords to prevent them from reusing an old password? The only way I’m thinking it’s somewhat possible would be to assign each user a randomized key (I’m not loving calling it a pepper) and storing it secured separately from the rest of their data, using it on each password before hashing, and then checking their new password against the old hashes by running it through the hash process with the key. Even then, though, there’s a problem. Figure out one of a person’s old passwords, you can figure out the key, then you have all of their past x passwords assuming you have access to the database. Unless you randomize the key every time they do a reset and store the last x keys as well in the same order, again in a separate location from the hashed passwords. There's two things that generally happen. The first is that the system keeps X number of previous password hashes (salted obviously), and compares against them to make sure they're not being re-used. Losing those are about as bad as losing the live hash so meh, not really any additional exposure there. Password change prompts also typically require you to enter the current password before setting the new one; this gives the system leeway by having the password in plaintext at the moment to compare to see if they're attempt to do some kind of reuse pattern by matching strings in it against each other and rejecting if they're too similar. Then you discard the plaintext when done, you do don't have to come up with some kind of reversible encryption mechanism to do the comparison that may bite you in the rear end down the road if the system is compromised.
|
|
#
?
Jun 12, 2019 20:36
|
|
|
Our password policy, and my previous company‘s forbade the previous 6 passwords, and AD enforced it, but I have no idea how AD does it, as I am just a lowly computer toucher. Which policy, I might add, just results in the same password + a number being used, and the number just iterates until it gets to “6” in our case, and going back to “1”.
|
|
#
?
Jun 12, 2019 20:40
|
|
|
Yeah I mean I don't see why you wouldn't just store them exactly like current passwords. The hashes should be secure enough that if the database is breached they can't be reversed. IMHO you shouldn't be allowed to ever reuse a password, regardless of age. Just add the date you changed it to the end. That's something only you (and maybe system logs) ought to know anyway.
|
|
#
?
Jun 12, 2019 20:40
|
|
|
Cup Runneth Over posted:Yeah I mean I don't see why you wouldn't just store them exactly like current passwords. The hashes should be secure enough that if the database is breached they can't be reversed. Seems like if you bust a hash and get a password ending in a recent date, you have a pretty good hint at what you should try by brute force. No?
|
|
#
?
Jun 12, 2019 22:14
|
|
|
Darchangel posted:Our password policy, and my previous company‘s forbade the previous 6 passwords, and AD enforced it, but I have no idea how AD does it, as I am just a lowly computer toucher.
|
|
#
?
Jun 12, 2019 22:19
|
|
|
evil_bunnY posted:Compares the new password to the old hashes, which is why very minor changes will go through. Good systems will compare the live password to the new one but still can't compare to the older ones (because one way hash). You can hash and save normalized versions too (case folded, for example) to catch more variants of almost-reuse.
|
|
#
?
Jun 12, 2019 22:39
|
|
|
PBS posted:I would just think they'd keep and compare your previous hashes. Your current password will exist in hashed form, I don't know why you'd go to extra effort to further secure past ones beyond how you store the current. I know very little about the actual technical aspects of information security (as evidenced by my posts  ), but wouldn't that require using the same salt every time? You would have to store that somewhere, right? Which means either you have it in the code of the program and use the same salt for everyone, which means if you get one password you get them all, or you have to store an individual salt per person somewhere. Right? If you generated a salt every time someone reset their password, you wouldn't be able to compare the previous ones to the new one.I mean I guess you could mitigate the first approach by pseudorandomly generating the salt based off of other aspects of the person's profile? Stuff that couldn't be changed. Then if they get one salt they have one person's passwords, and the only way they could reverse engineer the salts would be to put a whole lot of processing power behind figuring out what the algorithm for generating the salt used out of the profile details and how. This company's security practices are generally a dumpster fire, so I wouldn't be surprised if they do it a bad way, but they also have a few actually good practices and in the onboarding training they teach everyone that password length is more important and effective than adding numbers or special characters in place of letters. Which was a nice surprise. But it's still the place that has all of the administrator credentials for a large chunk of our clients' systems stored in plaintext on Sharepoint.
|
|
#
?
Jun 13, 2019 01:15
|
|
|
Admittedly this method would be slow if you used something like BCrypt and you're better off just rate-limiting rather than storing passwords that have been used previously. Force the users to have a half-decent password from the start. Or maybe y'know don't write your own authentication scheme if at all possible. I am not a fan of suggesting the use of Google, Facebook, Apple, or whatever, but you can at least hand off that problem to them and gain things like 2FA. If it is an internal app, make use of ADFS, AzureFS, LDAP itself, or whatever you use for internal authentication.
|
|
#
?
Jun 13, 2019 01:30
|
|
|
ADFS and SAML is my crusade eventually all services will fall under my identity and authentication management
|
|
#
?
Jun 13, 2019 01:34
|
|
|
22 Eargesplitten posted:wouldn't that require using the same salt every time? 22 Eargesplitten posted:If you generated a salt every time someone reset their password, you wouldn't be able to compare the previous ones to the new one. but you don't have to think about any of this because bcrypt handles the salt for you. you should be treating its output as opaque and not generating or handling the salt directly 22 Eargesplitten posted:I mean I guess you could mitigate the first approach by pseudorandomly generating the salt based off of other aspects of the person's profile? Stuff that couldn't be changed. Then if they get one salt they have one person's passwords, and the only way they could reverse engineer the salts would be to put a whole lot of processing power behind figuring out what the algorithm for generating the salt used out of the profile details and how.
|
|
#
?
Jun 13, 2019 01:39
|
|
|
The Fool posted:ADFS and SAML is my crusade We enshrined this in policy. Any new SaaS application must support SAML. We've now helped 3 small boutique SaaS vendors implement SAML support. Usually we're able to get them to do it for about $2k one-time fee written into the SoW, meeting them half-way on their costs.
|
|
#
?
Jun 13, 2019 01:39
|
|
|
Ranter posted:We enshrined this in policy. Any new SaaS application must support SAML. We've now helped 3 small boutique SaaS vendors implement SAML support. Usually we're able to get them to do it for about $2k one-time fee written into the SoW, meeting them half-way on their costs. you are doing the lord's work 
|
|
#
?
Jun 13, 2019 02:28
|
|
|
The Fool posted:ADFS and SAML is my crusade I've been barking at vendors that don't provide SAML or AD authentication in their appliances.
|
|
#
?
Jun 13, 2019 02:29
|
|
|
My biggest problem are companies that gate SAML behind their highest pricing tier. E: I also have a problem with a vendor that has an app that integrates with SharePoint but doesn't support modern authentication, therefore MFA doesn't work on their app.
|
|
#
?
Jun 13, 2019 02:34
|
|
|
The Fool posted:My biggest problem are companies that gate SAML behind their highest pricing tier. Those companies should be fired if you’re dealing with them. It is irresponsible of them to do that.
|
|
#
?
Jun 13, 2019 05:24
|
|
|
I don't disagree, but for a lot of customers things like "security" and "proper authentication" are not desirable, so they don't demand them, and then those things become an afterthought line item rather than a core competency.
|
|
#
?
Jun 13, 2019 14:01
|
|
|
Lain Iwakura posted:Those companies should be fired if you’re dealing with them. It is irresponsible of them to do that. To my first complaint, the primary offender is Adobe and as much as I'd like to, we aren't going to be able to get rid of them anytime soon. To my second complaint, we're working on it, but for now we have an ADFS claims rule that limits logins to the local network only.
|
|
#
?
Jun 13, 2019 20:15
|
|
|
The Fool posted:To my first complaint, the primary offender is Adobe and as much as I'd like to, we aren't going to be able to get rid of them anytime soon. We had an issue with Adobe Acrobat and ADFS due to our non-persistent VDI. They basically stopped offering serial keys with their cloud products, so you have to use their "log into account = licensed" scheme. The problem is that it would intermittently log users out between VDI sessions with no rhyme or reason. Then add in that the user actually had to log in, instead of SSO just logging them in automatically, and it was a huge headache. Users would be prompted for username and password and when they'd enter the username field and tab/click down to password, it would pass them through. Problem with that is users would panic and call because they didn't know their password. ~6 months of troubleshooting with Adobe and they could never figure it out. They also couldn't say that they were working on login-less SSO. The poo poo I had to pull to get us a refund on our yearly subscription so we could outright buy non-cloud licenses was insane. It was one of the dumbest and most painful things I've had to deal with in IT. Their outsources support and "developers" were completely awful and there was no one in North America that knew enough or cared enough to escalate to. I had to threaten our VAR to switch all of our business to another VAR to get it resolved. [Edit: The authentication would then cause all sorts of awful problems. It would break the Adobe Distiller, even once users got logged into Adobe Acrobat. Same with the PDF preview pane, the browser plugin, etc. gently caress Adobe.]
|
|
#
?
Jun 13, 2019 21:49
|
|
|
Internet Explorer posted:We had an issue with Adobe Acrobat and ADFS due to our non-persistent VDI. They basically stopped offering serial keys with their cloud products, so you have to use their "log into account = licensed" scheme. The problem is that it would intermittently log users out between VDI sessions with no rhyme or reason. Then add in that the user actually had to log in, instead of SSO just logging them in automatically, and it was a huge headache. Users would be prompted for username and password and when they'd enter the username field and tab/click down to password, it would pass them through. Problem with that is users would panic and call because they didn't know their password. Do you use fslogix by chance?
|
|
#
?
Jun 13, 2019 22:50
|
|
|
We did not. Citrix UPM.
|
|
#
?
Jun 13, 2019 23:11
|
|
|
Rufus Ping posted:no Okay, like 30 seconds before I posted my confusion I found the part I was missing: you store each salt in the database. I wasn't seeing how you would be able to compare to a hash made with a different salt, and then after that I realized that you wouldn't be able to match the hash of the current password if you didn't have the current salt somewhere either. For some reason I thought salts were a single use generated thing  Turns out I should have been looking on Stack Overflow instead of Wikipedia for an explanation of salting and rainbow tables. Do people still just concatenate the salt and the password or do programs tend to do some other kind of operation first, so you have to know whether to do (password + salt) or (salt + password) or (password AND salt) or (password XOR salt) or something even more complicated even after you get the salt? Thinking about it as best as I can after a long day at a lovely job, doing that would only help against dictionary attacks rather than basic brute force, but at this point without a Chinese bitcoin farm brute forcing bcrypt without knowing anything about the password length or character restrictions seems like a fool's errand (someone will probably tell me why I'm wrong).
|
|
#
?
Jun 14, 2019 01:26
|
|
|
Internet Explorer posted:We had an issue with Adobe Acrobat and ADFS due to our non-persistent VDI.
|
|
#
?
Jun 14, 2019 23:18
|
|
|
22 Eargesplitten posted:Do people still just concatenate the salt and the password or do programs tend to do some other kind of operation first, so you have to know whether to do (password + salt) or (salt + password) or (password AND salt) or (password XOR salt) or something even more complicated even after you get the salt? 1. XORing or whatever costs additional processing with zero real gain in security. If your systems are compromised someone might be able to just look at your code to see that you're doing some dumb passsaltword jumble. And even if only the database is stolen, there's only so many ways to run two strings together. If you've run a couple attacks through your GPU and keep geting zero hits, you're going to start thinking about changing around the hashes eventually. 2. It's a maintenance and uniformity problem. If you have two or more different applications that hit the password database, they have to do the same thing. Now your web developers have to go explain their non-standard scheme to the phone app team. quote:Thinking about it as best as I can after a long day at a lovely job, doing that would only help against dictionary attacks rather than basic brute force, but at this point without a Chinese bitcoin farm brute forcing bcrypt without knowing anything about the password length or character restrictions seems like a fool's errand (someone will probably tell me why I'm wrong). GPU dictionary attacks are brute force attacks, just smart ones that attack psychological tendencies and bad habits. Salting protects against rainbow tables, GPU attacks overcome salting by running the whole dictionary through each salt/hash pair. Bcrypt isn't magic, and you don't need a bitcoin farm to attack the low-entropy passwords. Entropy requirements are hard to enforce, the dumb things people do to avoid length & character restrictions (dumbpa$$w0rd) work for a reason. And over time more of the passwords will become vulnerable as GPUs continue to get better.
|
|
#
?
Jun 15, 2019 15:08
|
|
|
When are we going to see machine learning harnessed to guess people's passwords?
|
|
#
?
Jun 15, 2019 18:58
|
|
|
Huh, it just keeps guessing "f@rts69" over and over again.
|
|
#
?
Jun 15, 2019 21:58
|
|
|
Volmarias posted:Huh, it just keeps guessing "f@rts69" over and over again. Because it learned which accounts use this password. It's correct each time.
|
|
#
?
Jun 15, 2019 22:04
|
|
|
Volmarias posted:Huh, it just keeps guessing "f@rts69" over and over again. why does my account keep getting stolen?!?!
|
|
#
?
Jun 16, 2019 05:45
|
|
|
That's what 2FA is for! Weird, it just keeps generating "420420" for every code
|
|
#
?
Jun 16, 2019 11:10
|
|
|
The Fool posted:To my first complaint, the primary offender is Adobe and as much as I'd like to, we aren't going to be able to get rid of them anytime soon. Do you have access to nuclear weapons?
|
|
#
?
Jun 17, 2019 16:58
|
|
|
Clever use of steganography here. Hope it works out.
|
|
#
?
Jun 17, 2019 23:54
|
|
|
This is pretty hilarious. Genius and Google have had sour relations for a very long time.
|
|
#
?
Jun 18, 2019 01:29
|
|
|
Anyone seeing activity on their public facing linux boxes for CVE-2019-11477? Looks like it's possible to kernel panic any linux server remotely by abusing the TCP stack that seems somewhat easy to exploit from my (somewhat under qualified) view. https://access.redhat.com/security/vulnerabilities/tcpsack edit: any *unpatched linux server that isnt freeBSD FungiCap fucked around with this message at 14:48 on Jun 18, 2019 |
|
#
?
Jun 18, 2019 14:46
|
|
|
FungiCap posted:Anyone seeing activity on their public facing linux boxes for CVE-2019-11477? Their original SA mentions FreeBSD, but I believe it's in the specific use-case they have (FreeBSD is the backbone of their ~100Gbps-per-box CDN called OpenConnect) Congratulations, you're one of the first people I've seen who didn't assume it applied to FreeBSD too - it only applies if you've got RACK enabled, which it isn't in the GENERIC kernel config on any supported version.
|
|
#
?
Jun 18, 2019 15:37
|
|
|
D. Ebdrup posted:It's super trivial to mitigate in most cases, though - and SACK/RACK isn't widely deployed, so it shouldn't impact too many people except Netflix. Thanks friendo.
|
|
#
?
Jun 20, 2019 01:23
|
|
|
Ladies, gentlemen, and friends, Eric S. Raymond. https://twitter.com/mjg59/status/1141786872387010561 For people with screenreaders: Bug report ESR posted:Hi, Project news quote:2.5.14: 2019-06-20::
|
|
#
?
Jun 20, 2019 20:31
|
|
|
Klyith posted:GPU dictionary attacks are brute force attacks, just smart ones that attack psychological tendencies and bad habits. Salting protects against rainbow tables, GPU attacks overcome salting by running the whole dictionary through each salt/hash pair. I meant brute force as in literally trying every possible combination of password, not so much trying commonly used / previously stolen passwords. I guess dictionary attacks are still brute force, just brute force that has evolved to the point of being a tool-user. I had also been looking at the time to guarantee getting the result, I guess it would be more accurate to give a LD50 of time spent attempting to crack a password of a given length/complexity. I was going off of the hashcat results I found for a Titan V or whatever they're at now, the newest ones. I just specified bcrypt because bcrypt hashing is several orders of magnitude slower than a lot of other methods going off of the results I've found. As in the Titan getting ~55k hashes per second as opposed to 10-15 megahashes on other methods. Although I guess if people made bcrypt ASICs then going off of the speed differences seen in cryptocurrency mining between high-end GPU mining rigs and ASIC mining rigs you would see, again, several orders of magnitude difference. Although it doesn't seem like any cryptocurrencies use bcrypt yet so I don't know if there are any bcrypt-compatible ASICs. Apparently FPGAs have been designed that work well with bcrypt though, so maybe approximate .5mhash there? gently caress if I know, numbers change way too fast on this stuff since it's an arms race on all sides.
|
|
#
?
Jun 25, 2019 21:27
|
|
|
Mozilla updated their TLS configuration guide for the first time in 2.5 years. Here's a summary of the changes:
|
|
#
?
Jun 28, 2019 18:36
|
|
|
|
| # ? Apr 19, 2024 14:23 |
|
|
Everything relying on GPG is hosed. quote:Executive Summary even more executive summary: poo poo, someone finally exploited this well-known problem. Choice quotes: quote:The software is Byzantine. The standard keyserver software is called SKS, for "Synchronizing Key Server". A bright fellow named Yaron Minsky devised a brilliant algorithm that could do reconciliations very quickly. It became the keystone of his Ph.D thesis, and he wrote SKS originally as a proof of concept of his idea. It's written in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that. This is of course no problem for a proof of concept meant to support a Ph.D thesis, but for software that's deployed in the field it makes maintenance quite difficult. Not only do we need to be bright enough to understand an algorithm that's literally someone's Ph.D thesis, but we need expertise in obscure programming languages and strange programming customs. quote:it's used in environments where a single mistake can cost millions and speed matters quote:The OpenPGP specification puts no limitation on how many signatures can be attached to a certificate. The keyserver network handles certificates with up to about 150,000 signatures. quote:We do not even know the scope of the damage. I'm sure someone will have pointed this out in the comments: quote:
There's a trivial "fix" for the keyservers: Limit the number of returned signatures to a client to something that GPG can handle unless it asks with "Hi, I'm a fixed version give me all of them". Harik fucked around with this message at 20:40 on Jun 29, 2019 |
|
#
?
Jun 29, 2019 20:38
|
|
