Gentoo GitHub repo hack made possible by these 3 rookie mistakes

The developers of Gentoo Linux have revealed how it was possible for its GitHub organization account to be hacked: someone deduced an admin’s password – and perhaps that admin ought not to have had access to the repos anyway. The distro’s wiki has added a page describing the SNAFU. It describes the root cause of the cockup as …

[Waseem Alkurdi]

That gives bad sysadmins an excuse

That *even* Gentoo can be hacked. Evil hackers, who are we to stand in their face?

[Anonymous Coward]

Re: That gives bad sysadmins an excuse

Gentoo didn't get hacked, their GitHub account did, (hardly hacking is it, guessing a poorly chosen method of nomenclature)

They also failed to secure it with 2FA.

Idiots

[Nick Kew]

Saved by github

Well, on that basis, this is entirely Gentoo's screwup and could equally well have happened on their own non-github infrastructure.

More than that, it was github noise - automatically generated email - that alerted folks to the issue. You tell us that, without that noise, it might have remained undiscovered for ... who knows how long? I hope gentoo's non-github infrastructure benefits from the safeguard of a comparable level of noise!

Whoops!

[DropBear]

And there goes any remaining credibility of those savvy commentards who insist that site-specific variation schemes are the best thing since sliced bread and the answer to everything, each time the futility of modern password management is being discussed. I'm sure someone arguing that it can all be fixed with an even more convoluted site-obfuscation algorithm that nobody could possibly ever guess will come along shortly...

[Anonymous Coward]

Downvoted, purely because of this

https://www.grc.com/passwords.htm

Use it, everywhere

[Robert Carnegie]

The problem seems to be that someone guessed that the password carnegie-123412341234-register (if it was me and Reg, which it wasn't) was a stonking clue for carnegie-123412341234-gentoo

I sometimes download random data to compose a password... but then I rearrange the characters before use. Then even the random provider can't guess what my password is. Two minutes later, neither can I, but I also write 'em down. Where I keep 'em, you'd have hurt me to get it... and if you're prepared to hurt me, then most people in my position would say you can have it.

I'm told by the automatic tester at https://www.my1login.com/resources/password-strength-test/ - another questionable web site, because all are; ironically, this is all that we use it for - that my typical formula of 6 random distinct consonants and 2 numerals is "as secure as Fort Knox" and takes 47 years to crack. I haven't actually used Xcsqpd14 as a password though. My formula fits password enforcement rules in most places; some demand a non-alphanumeric character as well. Twits; random is random is unguessable. They get ! at the end. However, one of our systems also uses ! as an escape character...

As for remembering the bollocks, it might not work for you but currently I'm converting either 5 or 6 of the characters into a semi-memorable phrase that reminds me of the password. This doesn't work first time but eventually does, with the rest of the password returning to my working memory as well. Then of course they make you change it... For Xcsqpd14 let's see... "excuse quip" (excuse pronounced as the verb, if it matter) works as a purely mental hint for Xcsqp ...

[Claptrap314]

And how do you know that every string generated by https://www.grc.com/passwords.htm isn't dumped straight into a database somewhere? Possibly with the IP address of the client?

There are scores or hundreds of near-trivial applications & libraries that can be used to generate high security strings. You don't need web scale for this.

[Anonymous Coward]

dumped straight into a database

Seriously this. From that page:

"Every time this page is displayed, our server generates a unique set of custom, high quality, cryptographic-strength password strings which are safe for you to use:"

That is asinine. It needs to be done client-side with a chunk of JS or with a native program, on the client CPU, not on the server... this URL is just another way to be lazy and maybe get slapped for it.

[jarfil]

A very simple and secure variation scheme

1. Pick a random 256-bit string as your master password.

2. Memorize it and destroy any copies.

3. Learn how to do SHA256 in your head.

4. Now, for every website, hash that master password with SHA256 using the website as a salt.

5. Success!

[Ilsa Loving]

<quote>And there goes any remaining credibility of those savvy commentards who insist that site-specific variation schemes</quote>

Who in the world would suggest such a thing as acceptable? Nobody who actually knows what they're doing, at least.

There is only one viable solution today for passwords: Using a password manager. Only then are you able to make a unique password on every site you log into. And you can make them as long and complex as the site will allow, making them that much harder to break.

And now you only have one password to remember (for your password manager) so you just need to remember one solid password.

[Anonymous Coward]

only one viable solution

Danger, Will Robinson.

Open a terminal, run pwgen, copy and paste into a plain text file and the site where I'm making an account. If anyone could ever read that file, the game was already over and now they're merely looting. So no need for master passwords, and especially no need for choosing to trust someone's code to do my copy-pasting for me, which also requires that I believe their source is secure, like they didn't have their GitHub account silently compromised...

[Anonymous Coward]

Quite honestly

This kind of bad practice is more common than people realise.

The weakest link in security protocols are not the protocols, but people not following best practices

It simply does not even enter their thought process

Two-Factor-Authentication, while not a silver bullet, is massively recommended!!!

We really are heading further and further towards the predictions in the film Idiocracy

[vtcodger]

Re: Quite honestly

Two points:

1. Any security scheme that depends on programming users is unlikely to work. (Exception: The protected information -- e.g. nuclear weapon Permissive Action Codes -- is so important that users genuinely respect the necessity for security).

2. Passwords are a major impediment to usability. 2FA is a much greater impediment.. If you insist on making stuff unusable, folks either won't use it or will use it and find ways to "simplify" usage. They will somehow bypass your security measures.

No, I don't know (an) answer(s). I just know that recommended security practices are not working well. And I suspect they are probably never going to work well except for a rather limited fraction of users.

[jarfil]

Re: Quite honestly

Security is about making it difficult for unauthorized people to gain access. This means any scheme that's too easy, will also be insecure. We've come to a point where we can use schemes that are much more difficult to an attacker than to a legitimate user, but they can only increase de difficulty by so much, so the requirement of complication is still unavoidable.

There is just no way to turn "1234" into a secure password.

[Anonymous Coward]

Re: Quite honestly

And as for 2FA for RDP into Windows Admin on an internal server...

Given that there's so many other ways onto a windows box if your internal network is already pwned, utterly pointless.

Doesn't stop us having to do ti though, because complaince :-(

[Anonymous Coward]

predictions

Last night I started to make a backup with Acronis and they have something like mystery meat navigation in that particular 'UI' (free WD Edition, build 33). There are little icons in a column on the left of the window which are obviously supposed to be obvious, but aren't. I was fairly disgusted to learn that when you hover on one, it doesn't even have a tooltip to indicate what the hell it is I am looking at... well, it reminded me of the hospital scene, like many modern 'UIs' do.

[Anonymous Coward]

How nice it has been to forget-- Win10 does that a lot, too. I guess I best get to memorizin'

[Aodhhan]

Complete Security Failure -- NOT a mistake

This only shows how lazy people are. No doubt the expertise existed to provide a thorough and accurate risk assessment of this system. If an in-depth investigation takes place, they will likely find, the internal security organization provided the risks associated with not using MFA along with fire IDs, restriction/segregation of privileges along with password policies.

Don't call this a mistake... it was a deliberate act to accept the risk.

The "I don't want to inconvenience my workers" snowflake, lazy, PC attitude doesn't work in most professional settings, especially when it comes to risk.

Get rid of plastic straws if you must, but don't accept moronic risk out of laziness and PC optics.

Oh... and you may wish to fire whomever decided to accept such risk, and please publicize their name, so everyone knows not to hire this individual to make risk decisions.

[Anonymous Coward]

I facepalm every time I come across those websites that deny you the ability to copy and paste your password, whether that be during its creation or when authenticating

I suspect they do it to stop bots, but man does it do my fucking nut in

Idiots

[jarfil]

It won't stop bots, all it stops is passwords going through the clipboard.

Arguably, having any password touch the clipboard is not safe, and you should rather use a password manager that can integrate with your browser, but the alternative of having people come up with easy passwords to type is even worse.

[Anonymous Coward]

I got to admit that's the weakness in my approach... I assume JS on any tab or window can spy on the clipboard, maybe even the alternate X11 one that I actually use (not the ordinary Ctrl+C one). Then I still have the problem of needing to trust the browser addon-- which, after the Stylish disaster, I probably don't.

[Anonymous Coward]

How long ago was it that NIST revised their password guidelines?

I guess they didn't get that memo, or maybe they did but it was TL;DR

[jarfil]

Good thing I try to pretty much ignore NIST, that way when they finally updated their password guidelines I was already compliant... and they still have a way to go to catch up ;)

[MarieAntOnNet]

Gentoops?

[Christian Berger]

It's a good example why a website can be a big security problem

I mean you can use git with github purely by using ssh public key authentication which is orders of magnitute more secure than passwords. However there's still the github website which cannot use public key authentication as browser vendors haven't been making this as comfortable as it's for ssh.

Now if github had some ncurses based system running over ssh, you'd never even need a password. Instead you'd send them your public key (e.g. via mail or via some webform) and get a user account based on that. You can submit more public keys once you're logged on where you can also select a username and so on.

[riclh]

I was once asked, in all seriousness, if the assembler compiler I was using was 'properly security certified'. I pointed out that the machine is question was a fancy UART 'chip' and the complier in question only output binary encoded bytes and we had provided the source code as well as a CRC of the ROM/Output contents to prevent any changes from that.

They never got back to me.

[EnviableOne]

Chops to Gentoo

At least they came out and said "My Bad", this is how not to be an idiot next time ...