←back to thread

489 points gslin | 9 comments | | HN request time: 0.001s | source | bottom
Show context
mrtksn ◴[] No.42191644[source]
Hands down one of the greatest services out there, stopped a racket and made the internet secure.

I remember a time when having an HTTPS connection was for "serious" projects only because the cost of the certificate was much higher than the domain. You go commando and if it sticks then you purchase a certificate for a 100 bucks or something.

replies(5): >>42191676 #>>42192385 #>>42192827 #>>42192905 #>>42193198 #
dachris ◴[] No.42191676[source]
There's still enough people out there who don't know better, manually (or auto-renew) purchasing new a certificate every year from their hosting provider like it's 2013.
replies(7): >>42191711 #>>42191799 #>>42191800 #>>42191829 #>>42191872 #>>42191976 #>>42192618 #
karel-3d ◴[] No.42191976[source]
I have dealt with banking environment when they required SSL with at least 1-year validity on the callback API URL. Which excluded Let's Encrypt.

We were looking for a SSL provider that had > 1 year old certs AND supported ACME... for some reason we ended up with SSL.com that did support ACME for longer lasting certs; however, there was some minor incompatibilities in how kubernetes cert-manager implemented ACME and how SSL.com implemented ACME; we ended up debugging SSL.com ACME protocol implementation.

Fun. We should have just clicked once per 3 years, better than debugging third parties APIs.

No, I don't remember the details and they are all lost in my old work emails.

(Nowadays I think zerossl.com also supports ACME for >1 year certs? but they did not back then. edit: no they still don't, it's just SSL.com I think)

replies(3): >>42192077 #>>42192133 #>>42197885 #
1. lol768 ◴[] No.42192133{3}[source]
> I have dealt with banking environment when they required SSL with at least 1-year validity on the callback API URL

Why are (some) banks always completely clueless about these things? Validating ownership of the domain more often (and with an entirely automated provisioning set-up that has no human weak links) can only be a good thing.

Perhaps the banking sector will finally enter the 21st century in another ten years?

replies(2): >>42192383 #>>42192487 #
2. Veen ◴[] No.42192383[source]
The problem is more likely one of regulation than technical knowledge. Banks hire very smart people who know that a lot of what they do is bullshit, but they're paid to comply with banking and security regulations that lag a long way behind technical advances. Banks are also inherently conservative in their technical choices, and for good reason.
3. karel-3d ◴[] No.42192487[source]
The banking sector usually goes with "checkbox security".

They have these really, really long lists what all needs to be secured and how. Some of it is reasonable, some of it is bonkers, there is way too much of that stuff, and it overall increases the price of any solution 10x at least.

But OTOH I can hardly blame them, failures can be catastrophic there, as they deal with real money directly and can be held liable for failures. So they don't really care about security, and more about covering their asses.

replies(2): >>42192910 #>>42198073 #
4. dspillett ◴[] No.42192910[source]
> some of it is bonkers

Some of it is truly bonkers and never was good practise, but much of the irritating stuff is simply out-of-date advice. The banks tend to be very slow to change unless something happens that affects (or directly threatens to affect) the bottom line, or puts them in the news unfavourably.

Of course some of it is bonkers, like HSBC and FirstDirect changing the auth for my personal accounts from “up to 9 case-sensitive alpha-numeric characters” (already considered bad practise for some years) to “6 digits”, and assuring me that this is just as secure as before…

replies(1): >>42192988 #
5. dizhn ◴[] No.42192988{3}[source]
That sounds like "we were truncating your id and pass before anyway".
replies(1): >>42193303 #
6. dspillett ◴[] No.42193303{4}[source]
I don't think so, because it would also imply they were also throwing away anything non-numeric, and I really hope nothing that stupid was going on. When the change happened everyone had to establish a new password.

I read it as “we have been asked to integrate an ancient system that we can't update (or more honestly in many cases: can't get the higher-ups to agree to pay to update), so are bringing out other systems down to the lowest common denominator”. That sort of thing happens too often when two organisations (or departments within one) that have different procedures, merge or otherwise start sharing resources they didn't previously.

7. BrandoElFollito ◴[] No.42198073[source]
I won't go into the idiocies banks implement. They usually have to because totally incompetent people tell them they have to.

One of the practices was pathetic to the point of being funny: you had to input specific characters of your password (2nd, 4th, 6th, etc - this was changing at each login) AND there was a short timeout. My children probably learned a few new words when I was logging in.

replies(1): >>42203392 #
8. jjeaff ◴[] No.42203392{3}[source]
I suppose the purpose of that was to signal to hackers that they ARE in fact storing all passwords in plaintext?
replies(1): >>42203599 #
9. BrandoElFollito ◴[] No.42203599{4}[source]
It is very likely, yes. After a year or so of this practice (people were writing down their password with digits under the letters to quickly match the request) the bank said that they now propose two "secure login forms" - the older one and a new, normal one.

Some time later they silently removed the first one.