From the department of forgetting to renew certificates
-
-
@PleegWat said in From the department of forgetting to renew certificates:
@Medinoc said in From the department of forgetting to renew certificates:
@levicki What is Normandy?
A region along the French coast across the channel from Britain.
A parish in Britain across the channel from France.
-
@levicki said in From the department of forgetting to renew certificates:
It's not even a security risk, it's just executive wankery.
Except it is a security risk to not have signed addons because a) malware can change unsigned addons and you won't know it and b) sites can trick you into installing (or other malware can drop it in your Firefox install) addons which can steal your private data (passwords, credit cards, etc) and Firefox won't know to disable them because they weren't released through proper channel (weren't signed).
Then you reverse it when you renew your damn certificate.
That's two builds to make, test and release on CDNs for little benefit except to placate a few angry users of a free, unsupported, product.
And just as important (or more-so), now there is a build of FF out there that will forever not check for signed add-ons. Other sites can archive it and keep distributing it, or someone may never update their FF after that version for any number of reasons. So the intermediary release is far from a "temporary" fix. That idea is a big security no-no!
-
As far as I can tell, the interim release didn't disable add-ons signature checking, it instead added an up-to-date certificate.
-
@Zerosquare said in From the department of forgetting to renew certificates:
As far as I can tell, the interim release didn't disable add-ons signature checking, it instead added an up-to-date certificate.
He's responding to a hypothetical
-
Right. Forgot the context.
-
@Sumireko said in From the department of forgetting to renew certificates:
I also find it poetically ironic that Mozilla, being the biggest supporter of Let's Encrypt, has fucked their certificates. Even worse, they set it to expire on a weekend, when absolutely nobody was in office.
That's the absolutely-fucking-scary part. If a similar thing happens with LE, they'll take like half the intertubes down.
I don't get how they don't monitor shit like that. I mean, we have <100k users and monitor all our certificates, and they have how many millions? Jesus fuck.
-
@Parody said in From the department of forgetting to renew certificates:
They're rolling out an emergency fix through the Studies mechanism...
...the one they taught us all to turn off when they used it to deliver a Mr. Robot ad at the end of 2017.
This article about that event sums up the biggest problem with Mozilla/Firefox pretty well:
" To remove your browser from Firefox studies, user needs to go to about:preferences#privacy and uncheck the relevant checkbox.
Once completed, Firefox is back to being a good browser, albeit one that needs constant vigilance to prevent the next great idea from Mozilla HQ from adding functionality you don't want."
-
@El_Heffe said in From the department of forgetting to renew certificates:
[...] albeit one that needs constant vigilance to prevent the next "great idea" from [vendor] from adding "functionality" you don't want.
... just like about any other piece of software from the current decade
-
@levicki said in From the department of forgetting to renew certificates:
@anonymous234 said in From the department of forgetting to renew certificates:
Ideally: hard-code the checker to trust the expired certificate.
Nonsense. Never subvert proper checking.
Honest question: What's the logic behind certificate expiration dates?
-
@boomzilla said in From the department of forgetting to renew certificates:
Honest question: What's the logic behind certificate expiration dates?
To protect the CA. If you issue, say, a ten-year certificate the CA can't verify that the holder of the certificate is going to be the entity that they authenticated for that long. In fact, in that amount of time, compromise or some sort of mishandling of the associated key is very likely. So it's an additional control on top of the mechanisms customers have (but don't always use) to report change of contact information, change of ownership, loss of control of their key, etc.
Edit: In reviewing the CAB ballot that limited certificate lifetime to two years, I was also reminded that there are technical reasons-- when you apply new standards to new certificates (like moving to SHA-256), you don't really have a reason to revoke old certificates but you also don't want them floating around forever forcing you to keep legacy infrastructure in place (and forcing clients to accept them for a prolonged period of time when they'd rather not).
So, basically, because in order for a public-key infrastructure to be useful, subjects' identity should have been verified relatively recently and also the infrastructure should be able to evolve over time.
-
@heterodox said in From the department of forgetting to renew certificates:
@boomzilla said in From the department of forgetting to renew certificates:
Honest question: What's the logic behind certificate expiration dates?
To protect the CA. If you issue, say, a ten-year certificate the CA can't verify that the holder of the certificate is going to be the entity that they authenticated for that long. In fact, in that amount of time, compromise or some sort of mishandling of the associated key is very likely. So it's an additional control on top of the mechanisms customers have (but don't always use) to report change of contact information, change of ownership, loss of control of their key, etc.
I guess it's a poor man's revocation list. Although I suppose more reliable since the expiration always goes with it. But just asking for trouble for stuff like code signing. Unless as mentioned a post upthread that talked about timestamping, which I guess ensures that the code was signed when the cert was valid?
-
@boomzilla said in From the department of forgetting to renew certificates:
I guess it's a poor man's revocation list. Although I suppose more reliable since the expiration always goes with it. But just asking for trouble for stuff like code signing. Unless as mentioned a post upthread that talked about timestamping, which I guess ensures that the code was signed when the cert was valid?
It's not a poor man's revocation list but it does prevent revocation lists from becoming completely unwieldy since expired certificates can fall off them.
Yes, for stuff like code signing and document signing, a Time Stamping Authority (TSA) should always be used for long-term verification.
-
@boomzilla said in From the department of forgetting to renew certificates:
@levicki said in From the department of forgetting to renew certificates:
@anonymous234 said in From the department of forgetting to renew certificates:
Ideally: hard-code the checker to trust the expired certificate.
Nonsense. Never subvert proper checking.
Honest question: What's the logic behind certificate expiration dates?
Same as password expiration dates.
-
Ah, yes. Password expiration dates, coupled with password reuse policies, are why I end up with passwords like hunter2!!!!!!!!!!!!!! (n !s where n is the number of times my password has expired).
Filed under: Not really, Well, not anymore
-
I forgot to renew a registration on my (dead) mom's vehicle. Got a $60 parking ticket. Oh well.
Still need to sell that car. Been paying insurance for a car I don't drive for too long.
-
I'm late to this conversation, but I'm surprised no one has pointed out how most certificate signing authorities support Time Stamping Authority (TSA) servers precisely to avoid this kind of situation.
And yes, the industry's choice of acronyms here is terrible.
-
@powerlord said in From the department of forgetting to renew certificates:
I'm late to this conversation, but I'm surprised no one has pointed out how most certificate signing authorities support Time Stamping Authority (TSA) servers precisely to avoid this kind of situation.
Pretty sure three separate people have pointed that out by now.
-
@heterodox Toby faire, I think it's the frist time anyone has mentioned that most providers support it.
-
@HardwareGeek
We could batter a bid about the terrible name choices
-
@heterodox said in From the department of forgetting to renew certificates:
@powerlord said in From the department of forgetting to renew certificates:
I'm late to this conversation, but I'm surprised no one has pointed out how most certificate signing authorities support Time Stamping Authority (TSA) servers precisely to avoid this kind of situation.
Pretty sure three separate people have pointed that out by now.
Are you the TSAMA?
-
@levicki said in From the department of forgetting to renew certificates:
@error said in From the department of forgetting to renew certificates:
Ah, yes. Password expiration dates, coupled with password reuse policies, are why I end up with passwords like hunter2!!!!!!!!!!!!!! (n !s where n is the number of times my password has expired).
Feel free to share the above links with your IT admin.
They know. They don't care because idiocy is decreed from higher up than local IT has power to change.
-
@levicki said in From the department of forgetting to renew certificates:
@topspin said in From the department of forgetting to renew certificates:
They know. They don't care because idiocy is decreed from higher up than local IT has power to change.
They should quit their job if they are incapable of exacting change in the organization.
Nobody should accept so much responsibility without getting any authority.
Do you live in @pie_flavor‘s multiverse, too?
-
@levicki said in From the department of forgetting to renew certificates:
Nobody should accept so much responsibility without getting any authority.
Look at it this way: if they resign, they lose the job. If they stay and screw up big time one day, the worst that can happen is... they lose the job.
-
@levicki said in From the department of forgetting to renew certificates:
Nobody should accept so much responsibility without getting any authority.
Wow that made my day!
-
@levicki said in From the department of forgetting to renew certificates:
@Gąska said in From the department of forgetting to renew certificates:
Look at it this way: if they resign, they lose the job. If they stay and screw up big time one day, the worst that can happen is... they lose the job.
So you are encouraging status quo? As in, sit in the office, pretend you are doing any meaningful shit and get paid for that? Instead of, you know, doing stuff you believe is right?
If I'm unable to do stuff I believe is right, sure, why not. Mind you, I'd try to push as much as I can for adopting better practices in my environment - just like I'm doing now as a programmer.
As for resigning because they don't let you do things properly .vs. losing your job after an incident -- what do you think will be in your recommendations and your resume? Remember, you will be taking a fall, not them.
But the likelihood of things actually blowing up so much someone gets fired is very very low. Corporate life is different.
-
@levicki said in From the department of forgetting to renew certificates:
@topspin said in From the department of forgetting to renew certificates:
Do you live in @pie_flavor‘s multiverse, too?
No, I am just old enough to remember that people are born with a spine and that they are supposed to occasionally show they have it and stand up against fucking stupidity and tyranny.
Ugh.
So local IT makes me change my password every 6 months, forces me to use at least 3 out of 4 character categories (lower case, upper case, numbers,
blood of a virginspecial characters), checks that it isn't too similar to my previous password (defeating my scheme of changingfoo3
tofoo4
), etc.Yet, they have xkcd://correcthorsebatterystaple print-outs on the wall, so they know how annoying it is. So when I go
askbitchcomplain about it, it turns out these are implementations of strict rules set by central IT in Munich. Which, in turn are based on BSI rules, probably themselves based on old NIST rules. That this shit is outdated by now matters about as much as that it was always idiotic even back when the rules weren't considered outdated.This has exactly nothing at all to do with people having a spine, and everything to do with change in bureaucratic processes being slow at best. You can push for more change, but you can't just do whatever you want.
I doubt our whole IT department quitting their jobs over this would be a sensible move.
-
@topspin said in From the department of forgetting to renew certificates:
I doubt our whole IT department quitting their jobs over this would be a sensible move.
According to @levicki that makes the entire department spineless.
-
@topspin said in From the department of forgetting to renew certificates:
checks that it isn't too similar to my previous password (defeating my scheme of changing foo3 to foo4)
Those are the sorts of rules that make me angry, as they pretty much require that passwords are kept in the clear inside a database somewhere (or encrypted with a DB-wide key, and so might as well be in the clear), rather than properly salted and one-way hashed.
-
@dkf said in From the department of forgetting to renew certificates:
@topspin said in From the department of forgetting to renew certificates:
checks that it isn't too similar to my previous password (defeating my scheme of changing foo3 to foo4)
Those are the sorts of rules that make me angry, as they pretty much require that passwords are kept in the clear inside a database somewhere (or encrypted with a DB-wide key, and so might as well be in the clear), rather than properly salted and one-way hashed.
Depends on the form. The form might very well have three textfields: One for the current password, one for the new one and the last one to confirm the new password.
That way you can compare the old against the new password without having to store it somewhere.
-
@Rhywden said in From the department of forgetting to renew certificates:
@dkf said in From the department of forgetting to renew certificates:
@topspin said in From the department of forgetting to renew certificates:
checks that it isn't too similar to my previous password (defeating my scheme of changing foo3 to foo4)
Those are the sorts of rules that make me angry, as they pretty much require that passwords are kept in the clear inside a database somewhere (or encrypted with a DB-wide key, and so might as well be in the clear), rather than properly salted and one-way hashed.
Depends on the form. The form might very well have three textfields: One for the current password, one for the new one and the last one to confirm the new password.
That way you can compare the old against the new password without having to store it somewhere.
<Insert XKCD of 5 million dollar encryption-breaking supercomputer vs $5 spanner to get the password of an encrypted hard drive>
If all passwords are stored hashed and salted then the "5 million dollar alternative" in this case would be to calculate a number of "close neighbour" passwords based on the new password and trying to hash them using the previous password's salt to see if one of them matches the old password hash.
But yeah, asking the old password for extra verification is of course the simple and cheap option.
-
@dkf said in From the department of forgetting to renew certificates:
@topspin said in From the department of forgetting to renew certificates:
checks that it isn't too similar to my previous password (defeating my scheme of changing foo3 to foo4)
Those are the sorts of rules that make me angry, as they pretty much require that passwords are kept in the clear inside a database somewhere (or encrypted with a DB-wide key, and so might as well be in the clear), rather than properly salted and one-way hashed.
You enter your previous password to change it, so e.g.
passwd
knows your password the moment you try to change it.
Similarly, checking that the new one it isn't identical to your last N passwords also doesn't require anything like that. But I don't know if checking your last N > 1 passwords for similarity would work without weakening the system.EDIT: Also, I guess I caused confusion what "previous" refers to in the process of changing from one password to another. I meant "current" ("previous" wrt to the new one), but I guess you read it as "the one before current".
-
@topspin Certainly requiring the user to enter an 'old' password won't work, since they generally can't be expected to remember it.
-
@levicki said in From the department of forgetting to renew certificates:
Btw, password complexity rules are stupid. What if I use password
September11!
? It has 12 characters, capital letter, number, and special character, so it's strong, right? No it's not, even if it ticks all the boxes the resulting entropy is only 25 bits which is worse than some more complex 8 character passwords. People writing those rules sometimes really have no clue how things work.I don't disagree about the bullshit rules but just place yourself into the role of someone writing those rules. It's difficult writing in plain and simple words why one password is stronger than the other. Telling people about entropy will likely make them think of scary diseases.
-
@JBert said in From the department of forgetting to renew certificates:
Telling people about entropy will likely make them think of scary diseases.
That's why you just give them a password strength meter. It's powered by your entropy measure, but it seems much more intuitive to ordinary users.
-
@levicki said in From the department of forgetting to renew certificates:
@error said in From the department of forgetting to renew certificates:
Ah, yes. Password expiration dates, coupled with password reuse policies, are why I end up with passwords like hunter2!!!!!!!!!!!!!! (n !s where n is the number of times my password has expired).
Feel free to share the above links with your IT admin.
The thing that gets lost out of the original NIST recommendation to move away from password expiration dates is that the recommendation is made in conjunction with actual multi-factor (authenticator-based) authentication on the account in question as well.
Which means your Windows domain account CAN'T meet the requirement without significant extra setup & administrative overhead, as there's no built-in mechanism by which an AD account can require multi-factor authentication for logging in to a computer console (at the keyboard) session.
-
@izzion Yeah, no. Research shows that password expiration is counterproductive and the NIST recommendation recognizes that. MFA is separate from that.
Here's the relevant paragraph:
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
It makes no mention of a reqirement for using MFA - instead it uses quite strong words to expressly forbid periodical password changes.
-
Actually, SP 800-63B Section 4: Authenticator Assurance Levels lists what combinations you can use for what level of security, and SP 800-63 Section 6: Selecting Assurance Levels then tells you what level of security one should pick for what use case.
So @izzion is right that it's definitely in there, it's just not repeated in SP 800-63B Section 5 where they're talking about each of authentication mechanisms seperately.
-
@JBert The mandate to move away from periodical password changes is completely independent of that or they would have added qualifiers / conditions.
-
@Rhywden said in From the department of forgetting to renew certificates:
The mandate to move away from periodical password changes is completely independent of that or they would have added qualifiers / conditions.
It almost certainly stems from the observation that when periodic password changes are mandated, the nearly universal response of users is to adopt worse security practices (such as writing the password on a sticky note beside the monitor!) making the organisation's goals with the password changing be widely missed in reality.
-
@topspin said in From the department of forgetting to renew certificates:
So local IT makes me change my password every 6 months
It's 60 days for us, I think. I've got three AD accounts (my normal account, a privileged account for admin access to specific Windows servers, and another privileged account for access to servers on our non-Production domain) so I get three times the fun. Plus another couple of local accounts on servers in the DMZ which aren't joined to either domain.
For consistency I have an account on our UNIX LDAP (which is separate for reasons) which never expires the password.
-
@loopback0 I also have three domain accounts for similar reasons. I just reset all three at the same time, to the same password.
-
@Unperverted-Vixen said in From the department of forgetting to renew certificates:
to the same password.
That seems to defeat the point of separate logins slightly. They're fairly similar though - same letters, different upper/lower case combination.
-
@loopback0 said in From the department of forgetting to renew certificates:
@Unperverted-Vixen said in From the department of forgetting to renew certificates:
to the same password.
That seems to defeat the point of separate logins slightly.
:that'sthepoint.jpg:
The way I see it, the extra account isn't there to provide additional security. It's there to introduce friction to make sure I'm not making production changes on accident. Normal account has read-only access, but I need to elevate before writing.
And the third account is there because of a bug in our processes. (Only an account in domain X can administer users/groups in domain X, and I need to make changes in two separate domains. The two elevated accounts have identical permissions otherwise.)
-
@Rhywden said in From the department of forgetting to renew certificates:
it uses quite strong words to expressly forbid periodical password changes.
SHOULD NOT is less strong than SHALL NOT. It is a recommendation, not a requirement.
Our passwords expire regularly, but we can't make new ones. Instead, there is a web portal that presents you with 30 or so random character combinations per page, and you select one from the list.
I wrote a program using Puppeteer (headless Chrome) that scrapes random passwords and assigns each one an "easiness score," using a set of rules including dictionary words, consistent casing, and sequences. It then shows me the easiest available passwords and I pick from that.
-
@levicki
As of the last time I researched that product (about 2 months ago), it didn’t provide MFA for authenticating the session when someone sat down at a computer and logged in locally. You can get MFA with most VPN connectivity or with the major applications (Outlook, Skype, OneDrive, etc), but not for the main console login.Which is why our security guy hasn’t approved us removing our password expiration policy, despite my best efforts to argue for it.
-
@loopback0 said in From the department of forgetting to renew certificates:
@topspin said in From the department of forgetting to renew certificates:
So local IT makes me change my password every 6 months
It's 60 days for us, I think. I've got three AD accounts
This would definitely make me write down passwords
For consistency I have an account on our UNIX LDAP (which is separate for reasons) which never expires the password.
Same here, but using almost the same password rules as the Windows one. Which means I usually try to keep the passwords the same, but sometimes it doesn't quite work out.
-
@topspin Yeah, what I've seen on the one system I've used that kept a password history was checking the current password for similarity and the previous N for equality.
Leading to a naming scheme of foo1, bar2, foo3, bar4 etc. whenever the password expired (which was quite often!). Thankfully we no longer use this system.
-
@error said in From the department of forgetting to renew certificates:
Our passwords expire regularly, but we can't make new ones. Instead, there is a web portal that presents you with 30 or so random character combinations per page, and you select one from the list.
The Guaranteed-PostIt-Password policy.
-
@Medinoc My online payslip provider makes me change password every 60 days, and it does not allow duplicates. I don't much give a toss about this password being secure, the only personal information it gives out is my name and NI number, which are both easily obtainable anyway. Who cares if someone can see how little I get paid? For this reason, I used a simple password, easy to remember, when I first signed up. Then, 60 days later made me change. I've been in the same job 5 years now, so that's a lot of 60 days. It still won't let me repeat any of them. I suppose it's eventually forced me to make more secure passwords at least. Now it's literally a random sequence that I just let the browser remember for me. It's only a once a week check to make sure they've got my pay right anyway. I have no idea what my current password for it is, although I could find out by asking my browser.