31–40 of 76 posts
2FA is great for the web UI, but none of these vendors make it particularly easy to enforce 2FA on the command line.
Exactly. PATs are designed to circumvent human intervention (MFA) for authentication in order to support automation. I am very curious if there's a better way than PATs.
2FA is great for the web UI, but none of these vendors make it particularly easy to enforce 2FA on the command line.
Is it common that companies share intelligence like this? I think it's a wonderful idea, given they all operate on essentially the same service (git) they share similar security concerns.
Earlier quoted context omitted.
How so? An SSH key is a single factor. You could argue that a password-protected private key provides a second factor, but that still falls in the category of "something you know."
How many people can recite their SSH key? Surely an SSH key is "something you have".
The fact that one time passwords expire and change is what makes them a different factor than a static password.
1. Stop using 'git add .' This is a bad habit I see people keep suggesting to new git users. Stop recommending it and stop doing it. 2. Never store your password in .git/config. Why are you doing that? That shouldn't be stored in .git/config.
2FA is great for the web UI, but none of these vendors make it particularly easy to enforce 2FA on the command line.
An ssh key is 2FA
1. Stop using 'git add .' This is a bad habit I see people keep suggesting to new git users. Stop recommending it and stop doing it. 2. Never store your password in .git/config. Why are you doing that? That shouldn't be stored in .git/config.
Why are people using passwords instead of keys?
Earlier quoted context omitted.
The threat cited in the article said not just that the code would remain deleted, but that it would be "leaked" - presumably many of these were private repos. You could never trust that the attacker actually deleted their copy of the repo, but then, the whole cryptolocking business model falls down if the attacker isn't at least moderately honest, so I can see why people would respond to that threat.
”the whole cryptolocking business model falls down if the attacker isn't at least moderately honest” Nitpick: it only requires most attackers to be somewhat honest. Having a few unscrupulous ones may make life harder for the “honest” ones, but they themselves can be better of, e.g. by, after receiving payment, demanding more money.
Since literally everybody who has cloned a repo has a full copy of it, and since git is a decentralized revision control system, what on earth can it mean to hold a repo for ransom? The write up even says so: to recover, just push your code back up to our repo. I really don't understand what they are talking about. It's as if someone showed me a photo of my child and said, "pay me or I'll burn this photograph". What…
I don't keep all my git code local, only the projects I am currently working on.
That seems unwise. I don't have many local repos on this 128GB MacBookAir, but as well as BitBucket all the projects I have ever worked on are on other several machines and/or hard drives I have locally, and also zipped up in S3 buckets and on tarsnap.
Like they say, there's two kinds of people. People who've lost important data because they didn't back it up properly, and people who haven't yet.
1. Stop using 'git add .' This is a bad habit I see people keep suggesting to new git users. Stop recommending it and stop doing it. 2. Never store your password in .git/config. Why are you doing that? That shouldn't be stored in .git/config.
Why are people using passwords instead of keys?