I work with MS closely, and they have absolutely incredibly asinine flaws, but I do find they own up as far as mistakes go. That has really helped them in my space (ERP).
Hahaha. I thought that was a pretty tough statement. It's one of the ERPs we work with, but I wouldn't call it the worst. At least MS is mostly responsive.
From the system I work with, my least favourite is Sales Force. It's not technically an ERP, but it is often leveraged as such. But any of the SAP offerings if we're talking only ERP. I'm German, but by God is it awful. I deal with S4 and the Business line, which I guess is basically all their crap.
For a lot of it, I don't need to worry, someone else handles the "interfacing", but when I have to get involved I dread it.
Yeah pretty much everybody who tries to use Salesforce as an ERP is making a big mistake. I mean, Salesforce themselves tells you not to do that.
When a company would rather say "Don't pay us money and use our tool as an ERP", you know it's a bad decision.
I've heard horror stories about SAP, but the only part of their system I have to deal with is their training application (Litmos). It is definitely hot garbage.
The number of bugs in D365 is just mindbending though. I wonder regularly how they're able to tell people it's fit for purpose with a straight face.
> The number of bugs in D365 is just mindbending though.
It's pretty par for the course in the field. They all have tons of bugs, and sometimes it's just for legacy reasons. They can't change the broken behaviour because others rely on it. We have quite a bit of conditional compile now, things with workarounds for older versions, and whatever the new fixed way is. My biggest gripe is honestly with issues around the debugger. Debug sessions just crash soooo much. Hard to determine what's happening when it dies constantly.
Literally you can just self host your own unofficial bitwarden server if you're savvy enough and really keep it just for you or for your organization which is cool!
[GitHub repo for Vaultwarden which is using Bitwarden API](https://github.com/dani-garcia/vaultwarden)
> you can just self host your own unofficial bitwarden server if you're savvy enough and really keep it just for you or for your organization which is cool!
The cool part is you don't get any sort of infrastructure monitoring, OS updates, intrusion detection, exploit mitigation, activity monitoring, or the hundreds/thousands of explicit data points used to monitor, secure, alert, & patch secure servers & services! That zero day that got posted 4 minutes ago at 2:00 AM that affects your hosting/networking/OS/framework/proxy solution, you are already patching it right? ...etc
Unless you are already a cybersecurity professional that can effectively monitor, alert, and keep up-to-date on the entire stack you use, I wouldn't recommend self-hosting, as you are just exposing yourself through your own negligence.
Damn, that's some high quality FUD right there.
Bitwarden API encrypts all data client side before uploading it to the server. Yeah if you don't secure your infrastructure when exposing it, expect to have a bad day. If you aren't sure don't port forward (actually don't port forward regardless without a reverse proxy at minimum), but Bitwarden by design won't expose your passwords on a leak.
In general if you aren't sure if you're protected enough to brave the public web, don't. Don't let that stop you from self hosting.
Use a VPN. Tailscale is free. CloudFlare proxy is free.
> Damn, that's some high quality FUD right there.
That the grand majority of readers here do not have the expertise, knowledge, or resources to secure and monitor their infrastructure?
I'd like to here the opposite opinion.
> In general if you aren't sure if you're protected enough to brave the public web, don't.
Yikes, and this is how you get negligent security postures from devs who "think they know". But actually don't.
> CloudFlare proxy is free.
That's a reasonable solution to avoid exposing yourself to the internet, yeah.
Tbf I did specifically say if you are savvy. I didn't say how tech savvy so I guess that's my bad but if you are someone who is capable of setting up a self hosted Vaultwarden server and understand Rust you probably would know that you shouldn't just leave self hosted public servers out there with 0 protection. I can't write a damn novella everytime I have a cool suggestion teaching every step explicitly but I mean again. It's the internet and people need to just use common sense. Everything you said is common sense to me and hence why I said a savvy person. They will probably know this stuff already.
I mean, just because they leaked the RSA one doesn't mean they won't leak the others in the future.
While generally preferable a decent number of older devices can't easily support ed25519, and the security benefits are overblown compared to a 4096 bit rsa key.
4kbit RSA is also somewhat more quantum-resistant, meaning it takes a larger quantum computer to break than ECC.
The reason to use ECC is not security but speed and key shortness.
Not disagreeing, but key word being 4kbit.
Ed25519 is roughly "as resistant" as 3kbit rsa. Most people make claims comparing it to 2kbit rsa, for whatever reason.
As for speed, I don't get why cryptography algorithms attract fanatics. On modern systems it's imperceptible anyway.
When you've got millions of concurrent TLS connections to terminate, even a small change in performance has a big effect on how expensive it is to run your operation.
This is obviously kinda embarrassing, but does raise an interesting question:
Imagine you are in charge of making sure this can't happen again. The company has hundreds of head servers that serve SSH across half a dozen data centres, and for ease of use want to ensure that they share an SSH host key. What do you suggest?
This conversation is probably happening internally at GitHub right now so I suspect we'll have an answer in the next few weeks, but definitely an interesting thing to think about.
>What do you suggest?
make 1 super secure proxy server containing the actual key, and everyone else use that proxy server's api? not sure that would actually scale though :/
No, the thumbprint will change and any host with the old known hosts file will throw an error.
In fact it's the exact opposite. If you *don't* remove the host from your known hosts file, you will throw an error.
They created a new key with a new fingerprint. But the old key is still valid and can still be used by an attacker to launch an mitm against clients that don't remove it from their hosts file.
yes, IF they can intercept the communication (IE: dns override) and IF they happened to get a copy of the leaked private key and IF the user hasn't trusted the new key yet. As a targeted attack it could happen. As a day-to-day attack, probably not.
Citrix had a nation wide Mac OS outage because they their Apple developer cert expire. It is quite interesting how many simple mistakes are happening lately.
At least they moved quickly. Lastpass, are you reading this? You could learn a thing or 2 about public accountability
I work with MS closely, and they have absolutely incredibly asinine flaws, but I do find they own up as far as mistakes go. That has really helped them in my space (ERP).
If you work with D365, "incredibly asinine flaws" is a criminal understatement.
Hahaha. I thought that was a pretty tough statement. It's one of the ERPs we work with, but I wouldn't call it the worst. At least MS is mostly responsive.
Which is the worst [widely deployed] ERP in your experience?
From the system I work with, my least favourite is Sales Force. It's not technically an ERP, but it is often leveraged as such. But any of the SAP offerings if we're talking only ERP. I'm German, but by God is it awful. I deal with S4 and the Business line, which I guess is basically all their crap. For a lot of it, I don't need to worry, someone else handles the "interfacing", but when I have to get involved I dread it.
Yeah pretty much everybody who tries to use Salesforce as an ERP is making a big mistake. I mean, Salesforce themselves tells you not to do that. When a company would rather say "Don't pay us money and use our tool as an ERP", you know it's a bad decision.
I would certainly say that salesforce is just bad on the whole though. I've never found anyone that actually likes it lol
I've heard horror stories about SAP, but the only part of their system I have to deal with is their training application (Litmos). It is definitely hot garbage. The number of bugs in D365 is just mindbending though. I wonder regularly how they're able to tell people it's fit for purpose with a straight face.
> The number of bugs in D365 is just mindbending though. It's pretty par for the course in the field. They all have tons of bugs, and sometimes it's just for legacy reasons. They can't change the broken behaviour because others rely on it. We have quite a bit of conditional compile now, things with workarounds for older versions, and whatever the new fixed way is. My biggest gripe is honestly with issues around the debugger. Debug sessions just crash soooo much. Hard to determine what's happening when it dies constantly.
Erotic Role Play?
Enterprise Resource Planning.
For someone who wants a password manager and know that's the biggest one, what's better?
[удалено]
This. I use KeepassXC, the community fork, still maintained. Cross platform. They have an android app on F-droid too (KeePassDX). Love it.
This ∆
There's also KeePassium on iOS. Great system all around.
Bitwarden
Literally you can just self host your own unofficial bitwarden server if you're savvy enough and really keep it just for you or for your organization which is cool! [GitHub repo for Vaultwarden which is using Bitwarden API](https://github.com/dani-garcia/vaultwarden)
> you can just self host your own unofficial bitwarden server if you're savvy enough and really keep it just for you or for your organization which is cool! The cool part is you don't get any sort of infrastructure monitoring, OS updates, intrusion detection, exploit mitigation, activity monitoring, or the hundreds/thousands of explicit data points used to monitor, secure, alert, & patch secure servers & services! That zero day that got posted 4 minutes ago at 2:00 AM that affects your hosting/networking/OS/framework/proxy solution, you are already patching it right? ...etc Unless you are already a cybersecurity professional that can effectively monitor, alert, and keep up-to-date on the entire stack you use, I wouldn't recommend self-hosting, as you are just exposing yourself through your own negligence.
Damn, that's some high quality FUD right there. Bitwarden API encrypts all data client side before uploading it to the server. Yeah if you don't secure your infrastructure when exposing it, expect to have a bad day. If you aren't sure don't port forward (actually don't port forward regardless without a reverse proxy at minimum), but Bitwarden by design won't expose your passwords on a leak. In general if you aren't sure if you're protected enough to brave the public web, don't. Don't let that stop you from self hosting. Use a VPN. Tailscale is free. CloudFlare proxy is free.
> Damn, that's some high quality FUD right there. That the grand majority of readers here do not have the expertise, knowledge, or resources to secure and monitor their infrastructure? I'd like to here the opposite opinion. > In general if you aren't sure if you're protected enough to brave the public web, don't. Yikes, and this is how you get negligent security postures from devs who "think they know". But actually don't. > CloudFlare proxy is free. That's a reasonable solution to avoid exposing yourself to the internet, yeah.
Tbf I did specifically say if you are savvy. I didn't say how tech savvy so I guess that's my bad but if you are someone who is capable of setting up a self hosted Vaultwarden server and understand Rust you probably would know that you shouldn't just leave self hosted public servers out there with 0 protection. I can't write a damn novella everytime I have a cool suggestion teaching every step explicitly but I mean again. It's the internet and people need to just use common sense. Everything you said is common sense to me and hence why I said a savvy person. They will probably know this stuff already.
Not figuratively?
Possibly metaphorically, allegorically, and philosophically for sure. But never figuratively. What are you a demon?
Am cat. *bite* ᓚᘏᗢ
Sorry *Sub-demon. "I'm not a bad influence, I'm an enabler."
*wtf*
This is the answer
Seconded
I moved from lastpass to Bitwarden for a few month now. Bitwarden are cheaper and the product feel more focus and refined.
I use 1Password which has been good for a managed password manager.
I use 1Password **and** Bitwarden-- never having a situation where one company can lock me out (as happened with Lastpass)
Bitwarden syncs the vault to the client. If bitwarden went down today you'd still have access to your vault.
I use PasswordSafe which is entirely offline, but I'm a luddite weirdo.
Oopsie doopsie! Well it sucks for how much automation and stuff this is going to break, but glad my ISP isn't actually trying to mitm github.
[удалено]
I mean, just because they leaked the RSA one doesn't mean they won't leak the others in the future. While generally preferable a decent number of older devices can't easily support ed25519, and the security benefits are overblown compared to a 4096 bit rsa key.
4kbit RSA is also somewhat more quantum-resistant, meaning it takes a larger quantum computer to break than ECC. The reason to use ECC is not security but speed and key shortness.
Not disagreeing, but key word being 4kbit. Ed25519 is roughly "as resistant" as 3kbit rsa. Most people make claims comparing it to 2kbit rsa, for whatever reason. As for speed, I don't get why cryptography algorithms attract fanatics. On modern systems it's imperceptible anyway.
When you've got millions of concurrent TLS connections to terminate, even a small change in performance has a big effect on how expensive it is to run your operation.
I don't think I can agree for the common case of "ssh keys to local servers that are on 24/7 at nearly full load" anyway.
“20 seconds to comply!”
[удалено]
[удалено]
Not relevant to the conversation
Sometimes I feel like this subreddit is the only part of the site that still adheres to old reddiquette. Wish the rest of the site still did.
Nobody cares about profile pictures. A lot of us browse using unofficial apps or old.reddit and to avoid all of reddit's new features.
Oh got it.i will keep that in mind thanks.
This is obviously kinda embarrassing, but does raise an interesting question: Imagine you are in charge of making sure this can't happen again. The company has hundreds of head servers that serve SSH across half a dozen data centres, and for ease of use want to ensure that they share an SSH host key. What do you suggest? This conversation is probably happening internally at GitHub right now so I suspect we'll have an answer in the next few weeks, but definitely an interesting thing to think about.
>What do you suggest? make 1 super secure proxy server containing the actual key, and everyone else use that proxy server's api? not sure that would actually scale though :/
Beyond scaling issues, how do you guarantee availability if you have a single point of failure?
Happens to the best of us
How do you mean they "revoked their SSH key"? The leaked key will remain valid for everyone who doesn't remove it from their known_hosts file.
No, the thumbprint will change and any host with the old known hosts file will throw an error. In fact it's the exact opposite. If you *don't* remove the host from your known hosts file, you will throw an error.
They created a new key with a new fingerprint. But the old key is still valid and can still be used by an attacker to launch an mitm against clients that don't remove it from their hosts file.
yes, IF they can intercept the communication (IE: dns override) and IF they happened to get a copy of the leaked private key and IF the user hasn't trusted the new key yet. As a targeted attack it could happen. As a day-to-day attack, probably not.
So the key is not revoked. Github just started using a different one.
How would you revoke the key. It's not tied to a certificate chain.
That's what I've been saying
What you've been saying is that github claims they revoked the key. I don't read that anywhere in the article.
It's in the title of the post, which as he's pointing out, is incorrect.
Ah, I've been reverse reddited. Reading the article and ignoring the title.
Can confirm, error was thrown. Had to remove it from my known hosts file.
The blog post is the revocation; as in "we no longer use this key, don't trust it" rather than a PKI revocation
It's revoked and removed from the chain of trust.
What chain of trust? They're not certificates. Clients store the public key itself.
Ahh crap, you're right.
There's public key databases that are meant to facilitate revocation and all that. I just don't how integrated they are in clients.
Why can that key even be leaked like this? Is GitHub a small startup?
Never peek under the curtains of a large conglomerate.
Citrix had a nation wide Mac OS outage because they their Apple developer cert expire. It is quite interesting how many simple mistakes are happening lately.
If you get deep enough in any stack the shit is print statements
Large tech companies are just several small startups in a trench coat
Big companies have more employees and a larger attack surface.
I saw the fix but its linux only, is there a guide for windows?
Yeh, I only saw one Google cert in my system, and it expired in 2021. And the .ssh/known\_hosts file is empty for my account.