Attackers attack for a reason. For targets like my servers, they mostly want to install mining software or a DDoS bot. This is detectable via cpu or network monitoring.
I assume if someone wanted to extort money from me after encrypting the disks on my servers, I would also be somehow informed.
Was there a specific reason to use AGPL-3.0? Not critizing, just asking.
Tried to read about the license and was greeted by a tl;dr summary of the AGPL-3.0 license [1]. I am no lawyer but my gut tells me that providing such a summary is an invitation to strange disputes. Take care.
Also not a lawyer, but discussed this with multiple lawyers. As long as you make very clear that you're summarizing the legal document, but the legal document you're providing is the canonical truth, you're allowed to provide those kind of summaries.
For example, Creative Commons has a visual/bullet point explanation of their licenses. That's entirely okay, as the legal text is the core license.
I had a similar discussion with a lawyer once about a TOS that also included a summary. The lawyer told me that as long as you make it clear that your summary is just a summary, and is not the agreement, and you point out the actual agreement, you're okay.
In this case, the OP is pointing to the legal text clearly and merely summarizing it's most salient points.
"support or engage in terrorist or violent extremist offences"
What constitutes "support"?
Hopefully your next government is OK with you back then liking the post of that one organization previously not classified as terroristic.
My suspicion is this to rule out a specific hash. One well known to everyone interested in computer security back in the 1990's. One that haunts our nightmares to this day.
Back in my day, you see, there was this hash known as NTLM, which actually took your password and stored and then matched it in two ways, the NT hash (MD5 of your password in UTF-16) and the LM hash (split the first 14 bytes of your password in ASCII, then add parity bits and use that as a DES key to encrypt a well-known string). That LM hash was because they wanted it to be backwards compatible with Microsoft LanMan, introduced for OS/2 back in 1987. Even back in the 1990's it was a well known weak link, and given how trivial it is today to brute force a match for MD5 (since all characters after the first 14 can be arbitrary), you can see that this is simple to brute force with modern computing power. Microsoft has recommended NTLM not be used since 2010, but it's still in Windows for backwards compatibility reasons, and there are almost certainly still servers running today that a NTLM hash could get you access to. So that's my guess as to what they are targeting.
It predates bcrypt by quite a bit - descrypt would truncate password at 8 characters (or technically 8 bytes) and was used on a lot of older Linux and *NIX systems.
Ran into this exact issue on a project. The developer that implemented the solution wanted to make sure that we handled those 6 digit PINs in the most secure way with salt and pepper and bcrypt, and at the end of the day the system only actually checked the first two digits of the PIN because bcrypt ignored the rest.
Still a problem irrespective of algorithms used. I recently set up an account on a website, letting my password manager do its thing. Couldn’t log in. Turns out the password was too long (20 chars when 16 were allowed) and was silently truncated during signup.
The login form of course used the entirety of the password, not truncating it. Fun stuff.
Similar problem with Microsoft Dynamics Great Plains. I think the save-password window accepts more characters than get stored, so trying to log with the seemingly correct password a few times gets you locked out.
It also doesn't sanitise or warn about the password having impermissible characters that will mess up the user's account the SQL Server that backs GP. Then, after an admin tries to reset the user's password (typic'ly to something like "Password1!"), the user can log in with the insecure 'temporary' password as many times as they want, but cannot change to a new password. When the user tries, GP claims success and says to use the new password at next login…but when logging out announces that the password failed to change.
I ran into that with Paypal. Login limited my password length to something small (I think 20 characters?) but the signup page accepted my random 32 characters just fine.
I found out I could just enter the first 20 characters and log in. I've had other websites that simply broke. The worst one had a password reset page that also didn't verify their own password length limits, sending me in a frustrating password change loop.
Does this permit taking a sha 512 digest hash of the user input and returning that digest hash to the backend for proper password hashing?
My interpretation is that the entire password is being verified, even though the backend is only ever verifying a sha 512 digest hash of it.
(Oh and why would you do this? To be able to support arbitrary length passwords without opening yourself up to ddos attacks. Support as long passwords as the user wants - only the digest hash is sent.)
> The response has been what's called "safety certification":
This is the most scary part for me. Certifications are mostly bureaucratic sugar and on the other hand very expensive. This seems like a sure way to strangle your startup culture.
If customers require certifications worth millions, nobody can bootstrap a small business without outside capital.
Assuming the level of certification will be proportionate the potential risk/harm, then this is actually totally ok. Like would you want to fly in a plane built but a bootstrap startup that had no certifications? Or go in a submarine to extremely deep ocean tours of the titanic? Or put in a heart device? Or transfer all of your savings to a startup's financial software that had no proof of being resilient to even the most basic of attacks?
For me, its a hard no. The idea of risk/harm based certification and liability is overdue.
There's a different thread on HN about the UK Foundations essay. It gives the example of the builders of a nuclear reactor being required to install hundreds of underwater megaphones to scare away fish that might otherwise be sucked into the reactor and, um, cooked. Yet cooking fish is clearly normal behavior that the government doesn't try to restrict otherwise.
This type of thing crops up all over the place where government certification gets involved. Not at first, but the ratchet only moves in one direction. After enough decades have passed you end up with silliness like that, nobody empowered to stop it and a stagnating or sliding economy.
> Like would you want to fly in a plane built but a bootstrap startup that had no certifications?
If plenty of other people had flown in it without problems, sure? How do you think commercial aviation got started? Plane makers were startups once. But comparing software and planes (or buildings) is a false equivalence. The vast majority of all software doesn't hurt anyone if it has bugs or even if it gets hacked. It's annoying, and potentially you lose money, but nobody dies.
Commercial aviation was regulated because planes were killing people, and when it came in, air travel became the safest form of transportation. That isn't a coincidence. If the vast majority of software doesn't hurt anyone if it has bugs, then it won't require any certifications. If you heard me arguing for that, then you heard wrong. I am advocating for risk/harm based certification/liability.
Aren't you arguing for the status quo then? There are very small amounts of software that can cause physical harm, and those are already regulated (medical devices etc).
Financial harm and harm via personal records being hacked should also be included. The Equifax leak for example should have resulted in much worse consequences for the executives and also new software compliance regulations to better safeguard that sort of record-keeping.
Is there an existing comparison between pgManage and pgAdmin somewhere?
At first glance, it seems they serve the same purpose. Am i missing something? (besides the support for some other DBs - but pgManage states to target postgres primarily)
The main difference is that PgManage supports other databases too (although being mostly focused on Postgres support).
Some new features introduced originally in Postgres get ported to other databases too (table structure editor and ER diagam tools for example)
> Over the 20+ years, I witnessed a few security incidents.
As you said, the attackers who breached your system had ssh root access and you had no chance to detect them.