[HN Gopher] GitHub will require 2FA by the end of 2023
___________________________________________________________________
GitHub will require 2FA by the end of 2023
Author : database64128
Score : 191 points
Date : 2022-05-05 13:44 UTC (9 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| danirod wrote:
| PSA: you should ALWAYS download the recovery codes when you
| enable 2FA.
|
| Reading a lot of "phone broken; locked out of account" comments
| here and I don't know whether they understand that local one-time
| only recovery codes should be downloaded and stored safely (maybe
| even printed and stored in a safe, I do not know). If you lose
| access to your 2FA device, use the "recovery code" option and use
| one of your recovery codes to unlock your account.
| skrebbel wrote:
| But then where did the 2nd factor go? I mean how is a recovery
| key meaningfully different from a password, except that it's a
| random string chosen by the service instead of by me?
|
| Fear is being locked out is exactly why I'm reluctant to enable
| 2FA. To enable it and then just store the password (err, I
| mean, recovery key) in my password manager seems to just get me
| more hassle for exactly no additional security.
|
| What am I missing?
| michaelmior wrote:
| This is of course implementation dependent, but ideally a
| recovery key is single use. You should also be notified by
| email or some other channel that the recovery key was used.
| Then you are immediately aware if this use was unauthorized
| and you can take appropriate action. This type of response is
| not possible for unauthorized password use.
| em-bee wrote:
| you can get notifications for logins from a new device.
| isn't that just as useful?
| michaelmior wrote:
| I think there's at least a couple ways these are
| different:
|
| 1. It's easy to start ignoring such notifications if you
| regularly log in to new devices (or if logins expire). I
| don't think this is true to the same degree with
| notifications of recovery code usage.
|
| 2. Devices can potentially be spoofed.
| Arnavion wrote:
| The recovery key is different because it's "locked in a safe"
| and used rarely, if ever, instead of being used constantly.
| skrebbel wrote:
| But.. is passwords being used a common way for them to
| leak? I've never heard of this before but I'm no expert.
| Isn't the threat model either company databases being
| (badly hashed and) leaked, or password managers being
| hacked wholesale?
|
| I mean where am I supposed to store the recovery key if not
| in my password manager? My dropbox surely isn't better
| encrypted than my bitwarden. I work with the assumption
| that my password manager is the least insecure piece of
| data storage I use.
|
| I really don't get it. How isn't 2FA just security theater
| if we're all supposed to store the recovery keys "somewhere
| safe"? Can we really expect people to deal with recovery
| keys in a more responsible way than they do with passwords?
| Arnavion wrote:
| >I mean where am I supposed to store the recovery key if
| not in my password manager?
|
| My password manager (keepassxc) supports multiple
| databases. I store all TOTP recovery codes in a separate
| database (and with a different unlocking password) from
| the one that has regular passwords and the TOTP secrets.
|
| All my databases are backed up on someone-
| else's-computer, but I only keep the regular-passwords-
| and-TOTP-secrets database synced to my devices.
| nighthawk454 wrote:
| I think "ideally" you print out the codes and physically
| secure them somewhere, so the risk isn't high. Recovery
| codes aren't about safety from being hacked, they're
| about mitigating the risk of you losing your 2FA code
| device.
|
| In practice, 2FA is just another password anyway. What it
| really helps with is password reuse.
| LarryDarrell wrote:
| The best-case ordinary person is going to store them in
| "<user name>/My Documents/Security Keys/keys.txt".
|
| The average-case person is going to ignore the generated
| keys because they are deluged with nonsense every day and
| can't filter out what is important anymore. Lots of
| people will get locked out of accounts before they learn
| that there is now yet another unwanted tech bureaucratic
| layer to take seriously.
|
| I'm guessing in 5 years it will be normal to set up
| security questions for 2fa recovery keys. Or we'll add
| another 2fa for 2fa key recovery. The adding of layers
| will continue until we are all "secure" and we'll all
| have to ask for our misplaced keys from the NSA.
| a9h74j wrote:
| But what about on the server side? We generally know about
| passwords being salted and hashed. How are these recovery
| keys stored, regenerated etc? (I suppose they are also
| salted and hashed, but they are shorter and potentially
| easier to crack than good passwords, given a breach, no? Or
| just one longer, tougher recoveryKeyGenKey need be salted
| and hashed.)
| jwilk wrote:
| Recovery codes are generated by the server, so:
|
| * there's no temptation for the user to use them on another
| website, where they could leak
|
| * the server can ensure they are high-entropy (although
| AFAICS GitHub's recovery codes are only 40-bit...)
|
| Moreover, if someone takes over your e-mail account, they can
| reset your password; but they can't reset the recovery codes.
| skrebbel wrote:
| If this is all though, then couldn't we just use
| username+password auth but have the server generate the
| password? Why at the phone to the loop at all?
| dane-pgp wrote:
| Are you saying that iPhone-maker Apple and Android-maker
| Google (and TPM-mandator Microsoft) might not be able to
| imagine a future where the whole world isn't dependent on
| them for identity?
| jopsen wrote:
| Also print print out the QR code used to sign up for TOTP.
|
| That way it's easy to enroll a new laptop/phone/yubikey.
|
| Once printed out, put in a plastic bottle and bury it in your
| backyard :)
| VWWHFSfQ wrote:
| I made this mistake when I enabled 2FA for Uber some years ago.
| Same old story. Somehow forgot to grab my recovery codes for
| Uber even though I had for everything else. I got a new phone,
| manually transferred all my google auth codes from my old
| phone, somehow missed Uber. And then a few months later after I
| had already reset my old phone I installed the Uber app and
| oops, I needed a 2FA code. Couldn't get one. And because Uber
| is tied to your phone number I couldn't even just create a new
| account without getting a new phone number. So I emailed their
| support (which is useless), got a bunch of bot responses about
| how to reset your password, finally got one real person to
| respond after several weeks. But they had no idea what I was
| talking about and clearly had no ability to actually do
| anything about the 2FA issue. So I gave up and now I'm just
| permanently locked out of using Uber. Which is fine, cuz fuck
| 'em. Now I use Lyft exclusively. Which doesn't matter because
| in my experience every Uber driver is also a Lyft driver.
| pmoriarty wrote:
| _" they had no idea what I was talking about and clearly had
| no ability to actually do anything about the 2FA issue"_
|
| What are they supposed to do to fix your issue without
| compromising their security model?
|
| What you describe sounds like 2FA working like it's supposed
| to.
| VWWHFSfQ wrote:
| OK, replace "Uber" with your power company. You can't log
| into your account to update your expired credit card. Are
| they going to turn off your electricity because you dumb
| dumb didn't save your backup codes!
|
| No of course not. They're going to help you out. Because we
| live in the real world where people make mistakes.
| joshvm wrote:
| Most companies offer manual processes to get round failed
| 2FA - for example, provide copies of ID, a video chat to
| confirm, security questions about account details (eg last
| trips you took), etc. I've had to do this for a couple of
| services where the process was quite onerous, but that's
| the point.
|
| Doesn't help if you lose the keys and you're the only one
| that held them. This happened to me with an SSD that I took
| out of an old laptop, without realising that But locker
| stored its key on a chip in the laptop. I didn't even know
| that I had bitlocker enabled.
|
| But Uber shouldn't have your trip details behind end to end
| encryption, so they should be able to unlock it.
| pmoriarty wrote:
| ID can be easily faked.
|
| Security questions are often shared between services, so
| someone who's hacked any of the other services could get
| the answers to these same security questions and then use
| them to bypass 2FA.
| zackees wrote:
| Their security model locks users out.
|
| I nearly lost all my passwords with LastPass when something
| similar happened to me.
|
| Is grandma supposed to file her 128 character recovery code
| in a safe vault when she just wants to get from the
| airport?
|
| Stop blaming users for them not adapting to terrible
| authentication experience.
| pmoriarty wrote:
| I'd be interested in hearing about a better model.
|
| To me they're all terrible in one way or another.
| zackees wrote:
| If the security is this important then recovery should
| involve AI facial recognition with human fallback to
| unlock a device.
|
| Or else submitting a passport / drivers license to force
| unlock.
|
| We have global identity systems. Why not use them?
| lkbm wrote:
| Disconnect the phone number from that old account and allow
| him to create a new account using the phone number.
|
| If I cancel my phone service, and someone else later ends
| up with my phone number, does it make sense that that
| person can never use Uber with their new phone?
|
| Phone numbers are less transitory than street addresses,
| but much more so than email addresses. You should expect
| some amount of re-use, and need to be able to handle that
| situation.
| kmlx wrote:
| isn't it just better to use an app such as 1Password that can
| keep all your one-time passwords?
| photon-torpedo wrote:
| Then if the password manager is compromised, the second
| factor wouldn't add any protection over just a password.
|
| Then again, people that use password managers at all usually
| have stronger passwords and less password reuse, so it can be
| an acceptable tradeoff.
| tomrod wrote:
| Aye, but it assumes the company isn't keep the password in
| plain text.
| tarentel wrote:
| In my case it wouldn't anyway. Almost all of my 2FA is tied
| to my password manager as well. I am sure I am not alone in
| this. It is kind of scary to think about though.
| tuckerman wrote:
| I do the same but, for me, the threat of my password
| manager being compromised is much much smaller than the
| threat me not enabling 2FA out of laziness or the concern
| I might lose my 2FA codes. I keep my main email codes out
| of the password vault and that is enough to calm my
| nerves.
|
| Not everyone has the same risk profile/tolerance, but I
| just wanted to say that I don't think anyone should feel
| bad about doing the best they can, even if that stops
| short of the absolute best.
| tjoff wrote:
| This is why passwords are still king for many of us.
|
| And that the very same reason people can't be trusted with
| passwords is the same as why they can't be expected to keep
| backups of their recovery codes.
|
| Passwords suck. But so does every form of 2FA.
| eastbound wrote:
| Besides, where do you store your 2FA backup codes? At home??
| Where they could be stolen without your knowledge? Most
| people's homes are less safe than their online life.
| bcrosby95 wrote:
| I would be more concerned about fire or natural disaster.
|
| If your house catches on fire while you're asleep, there's
| decent odds both your phone and any printed codes are gone.
| danuker wrote:
| Maybe a safe or cameras would be useful for when you're not
| home. I sometimes leave my laptop on with motion started:
| https://motion-project.github.io/
| pmoriarty wrote:
| You could store them encrypted with a passphrase that only
| you know, so even if they're stolen they would be useless
| without your passphrase.
| TedDoesntTalk wrote:
| You could also encode them in DNA nucleotides and use
| CRISPR to modify your own DNA with your GitHub codes. /s
| joshvm wrote:
| The historic solution is in a safety deposit box at a bank.
| If you're talking about things like crypto cold wallets
| which might be extremely valuable, why risk leaving it at
| home? The cost for small items like documents tends to be
| reasonable. Good practice for things like ownership deeds
| and wills.
|
| I don't think the average home thief would know what to do
| with a printout of your 2FA recovery code especially if
| it's buried in other paperwork. The real risk is loss from
| negligence or natural disaster.
| faho wrote:
| With 2FA someone can break into your home, find your 2FA
| backup codes, defeat your password (e.g. by finding it in a
| leak) and they're in. If they are targeting you from your
| online life they need to first find out where you live and
| travel there.
|
| Without 2FA someone can defeat your password and they're
| in.
| oicU00 wrote:
| Funny story, I did store my Github codes in 1pwd
|
| Years go by, I need a code, they don't work. Github could do
| nothing but tell me to start a new account.
|
| Same old story; Github does not exist for you. It exists to
| make its workers and owners money. Whether it works or damages
| you is irrelevant to them.
|
| The future has no obligation to the past. Don't expect the
| codes to work if they change something that deprecates the old
| system they used.
| jrochkind1 wrote:
| I'll be honest.
|
| I don't believe I have the capacity to reliably preserve, in a
| secure location, recovery codes from dozens of different
| services over many years.
|
| I suspect I'm not the only one.
|
| There is pretty much nothing else in my personal life I have to
| do something like this with. The closest might be my physical
| SSN card or birth certificate. But that's one thing to keep
| track of, not a new thing every week or month to add to the
| stash. And even those, if they get lost, there is SOME way to
| replace them, usually.
|
| We are asking people to do something that is not a thing they
| have practice at or otherwise have to do or are any good at or
| have the capacity for. And then blaming them when they fail to
| pull it off, where you're constantly getting locked out of
| things and/or constantly getting hacked, probably both at once.
|
| I understand passwords alone don't work. I don't have a
| solution. I'm just predicting a very painful digital future for
| most people.
|
| (My own "solution" is using Authy TOTP, installing it on
| multiple devices, figuring I will retain working access to at
| least one of these configured devices, and not bothering with
| backup codes. I don't know how secure it really is, or TOTP is
| in general, but it lets me keep using services that require it,
| without living in fear that I'm going to lose my phone and
| misplace the backup codes and lose access forever).
| polote wrote:
| They do not give a single argument to show why they need to
| require 2FA, the same way they did not provide an argument for
| removing git password login. The more they will annoy users the
| more it will create space for a new service to compete with
| Github. Thanks Microsoft.
|
| The biggest problem with Github in my opinion, is that personal
| accounts are usually the same as the one we use in the company we
| work for. So we are mixing personal and professional security
| rapind wrote:
| I think the argument has already been made for 2FA often enough
| though. So they probably just assumed everyone had heard it
| (wrongly perhaps?).
| hqball wrote:
| We need someone like Homakov again
| (https://arstechnica.com/information-technology/2012/03/hacke...)
| so people can access their own repositories without this
| bureaucratic nonsense.
|
| If you have a strong password, is that really the biggest
| security threat? I highly doubt that. 2FA is used to get unique
| identifiers and data mine people.
|
| It is a breach of confidence that large parts of the open source
| scene has trusted GitHub and now has to jump through new hoops
| practically every year.
| vel0city wrote:
| > 2FA is used to get unique identifiers and data mine people.
|
| How do they get unique identifiers from TOTP?
| akerl_ wrote:
| TOTP doesn't have any shared identifier, just a shared randomly
| generated secret. FIDO2 generates unique IDs for each user/site
| pair, so there's no mining possible even if a user uses the
| same hardware token for multiple sites.
| potatoz2 wrote:
| I don't think it's true for the hardware token. The initial
| registration sends information about the token to the website
| (but the website can tell the browser it doesn't need it,
| IIRC).
| TimWolla wrote:
| WebAuthn supports sending an attestation certificate during
| the initial registration. But with an implementation
| according to the spec this certificate only identifies the
| model of the security key used and thus is shared across a
| 5 to 6 digit number of physical keys.
|
| This attestation is meant to allow the service to verify
| that you use a "blessed" security key with certain security
| properties (e.g. only a YubiKey 5 they verified to be
| secure and not some random $5 key with broken RNG off
| Amazon).
| codedokode wrote:
| This is bad. This, for example, allows sites to accept
| only government-approved hardware keys with backdoors and
| do not accept self-made secure keys.
| akerl_ wrote:
| This is intentional, given that "self-made" keys have
| plenty of ways to be insecure, and the average user
| cannot tell the difference between a well made key and
| one that is either accidentally or intentionally
| defective in ways that affect their security.
|
| FIDO2 is designed to maximize security for the majority
| of users, and the majority of users are using Yubikeys or
| other hardware-backed tokens provided by big players in
| their space.
| adg001 wrote:
| If for 2FA they mean a cellphone for the "offband" communication
| of a code, I am out.
| scrollaway wrote:
| They don't. Reading the article would have answered that
| question.
| aseipp wrote:
| It's an article concerning GitHub and security --- so you can
| rest assured nobody will read the article and they will
| instead flail wildly about how this is Basically George
| Orwell Doing 1984.
| adg001 wrote:
| I don't know about you, but I don't have time for reading
| everything gets published on the web - this is why I framed
| my sentence in the hypothetical. Reading my comment would
| have clarified my own point of view.
| aseipp wrote:
| Nobody cares and you aren't that important, so next time
| read the article instead and get over yourself.
| adg001 wrote:
| Speak for yourself.
| DocTomoe wrote:
| If this breaks my 'check in code automatically with ssh key
| authentication' workflow, I'll be shopping for another option.
| rapind wrote:
| I'm already using 2FA with github and it doesn't impact
| anything else (including git / ssh).
| skybrian wrote:
| It shouldn't, unless they change something.
| 101008 wrote:
| A colleague lost their phone and send an email to GitHub asking
| for a password and 2FA reset. It was sent from his account email
| and it was succesful. I found it weird because it means someone
| got access to his email Github would provide access to their
| account.
| teknopaul wrote:
| 2Fa is an excuse for we want more sales channels.
|
| You can put an auth cookie in a browser and achieve 2FA for 99%
| of use cases without bothering anyone.
|
| But nobody does that when they can use 2FA as an excuse to
| force people to install their app or hand over more personal
| information.
|
| No reason 2FA can't be just two passwords.
| tastyfreeze wrote:
| 2FA satisfies the "something you have" authentication type.
| Passwords satisfy the "something you know" type.
| na85 wrote:
| >2FA satisfies the "something you have" authentication
| type.
|
| In the general sense perhaps. As it's commonly implemented,
| no not really.
| staticassertion wrote:
| > You can put an auth cookie in a browser and achieve 2FA for
| 99% of use cases without bothering anyone.
|
| Confusing, obviously incorrect.
|
| > No reason 2FA can't be just two passwords.
|
| Maybe somewhat less obviously incorrect, but still incorrect.
| Passwords can be phished easily, are managed by users, etc.
| jacobsenscott wrote:
| If you can phish the pw you can phish the totp. People type
| it in right after they type in the pw.
| staticassertion wrote:
| Yes, but you can't guess a TOTP. You can guess a
| password. But I hope that Github will make their FIDO2
| support better.
| TimWolla wrote:
| Yes, but the TOTP is only usable once and cannot be
| reused across unrelated sites ("password stuffing"). And
| with WebAuthn / U2F the second factor is completely
| unphishable.
| ipaddr wrote:
| That doesn't make his point invalid. All this does is share
| your personal belief that passwords can be phished easily.
|
| You know what is less secure than a password? A phone. A
| phone is a sim swap away from being hacked at anytime.
| staticassertion wrote:
| I am against SMS 2FA.
| rascul wrote:
| > No reason 2FA can't be just two passwords
|
| That's not two factors, that's one factor (something you
| know) twice, even if it is different passwords.
| [deleted]
| MikeKusold wrote:
| The blog post only mentions Mobile Push and WebAuthN. Is Github
| deprecating TOTP 2FA?
|
| I also can't believe how many people are complaining about
| requiring 2FA. I have 2FA enabled for every single service that
| gives you the option. Backup Codes live in my password manager,
| and I have multiple yubikeys that I enroll whenever it's an
| option. It's been 10 years since I started doing this, and I've
| never been locked out.
| Destiner wrote:
| Wonder whether it's related to attack on Heroku.
| egberts1 wrote:
| That's my cue ... to exit GitHub ... and Google mail as well
|
| I don't have a phone number (that I am willing to fork over) so
| there's that.
|
| Welcome me, GITLAB!
| tarentel wrote:
| You don't need to give your phone number to enable 2FA on
| github. They'll annoy you every few months to give them your
| phone number as a backup but you don't need to do that. I hope
| it's never required either.
| mdb31 wrote:
| Well, given that Github today doesn't seem to support meaningful
| 2FA (only TOTP and SMS), wouldn't it be good to fix that issue
| before starting to talk about requirements like these?
|
| Maybe it's just my account, but I can't currently enroll my
| hardware token with Github in any way whatsoever.
|
| Sure, they offer some 1.5FA, but why would I bother with that?
| gkbrk wrote:
| I understand the SMS part, but what makes TOTP a not
| "meaningful" 2FA?
| mdb31 wrote:
| The TOTP "private key" can be easily cloned. Targeted
| malware, a database compromise at your app provider that you
| "securely" sync your settings to, or just a few minutes
| access to your "authentication" device, will do the trick.
| gkbrk wrote:
| There is no sync to provider servers on any TOTP
| implementation I use. Nor does a TOTP implementation need
| to be an application on a phone. Are you perhaps referring
| to the Google Authenticator or the Microsoft Authenticator
| apps when you refer to TOTP?
|
| Manufacturers that sell the "meaningful" 2FA hardware
| tokens can manufacture and sell duplicate keys, they even
| provide this as a service when you want backup keys. What
| makes you think they don't "securely" make a few duplicates
| themselves?
| mdb31 wrote:
| > There is no sync to provider servers on any TOTP
| implementation I use
|
| That's hard to dispute, but will you accept
| https://guide.duo.com/duo-restore as a counterexample?
|
| > Are you perhaps referring to the Google Authenticator
| or the Microsoft Authenticator apps when you refer to
| TOTP
|
| No, I'm referring to the actual RFC 6283 TOTP protocol.
| Which uses a trivially-cloned single private key. Which
| is, see the example above, in fact trivially cloned 'for
| convenience' by at least one widely-used 'enterprise'
| security solution.
|
| > What makes you think they don't "securely" make a few
| duplicates themselves?
|
| Since that literally makes no sense if you know how
| hardware tokens work.
| chipotle_coyote wrote:
| > or just a few minutes access to your "authentication"
| device
|
| Oh, come on. Your "hardware" "authentication" "key" can be
| stolen in mere seconds by someone with physical access.
| Clearly, we should dispense with that fake bullshit 2FA and
| require face-to-face verification. Drive to the GitHub
| office and let them run a DNA test to confirm your
| identity, or GTFO, amirite?
| klaustopher wrote:
| U2F has been supported for a while:
| https://docs.github.com/en/authentication/securing-your-acco...
| mdb31 wrote:
| Oh, that's lovely UX... "After you configure 2FA, using a
| time-based one-time password (TOTP) mobile app, or via text
| message, you can add a security key"
|
| So, after you enable a broken-by-design 1.5FA method, which
| you don't want, and which will further expose you to account
| takeovers, you can, _possibly_ configure actual security.
|
| No wonder these guys are raking in the big bucks...
| einichi wrote:
| They let you enroll a hardware token _after_ you enable either
| a TOTP or SMS 2FA method. No idea why, seems to defeat the
| point of the additional security that a hardware token offers.
| procombo wrote:
| Authenticator apps, and SMS help them derive you have
| identity -- which is more secure for them and you. Hardware
| token via WebAuthn (etc) is only more secure for you.
|
| When they say "for the sake of security" they mean for them
| too.
|
| There's a reason they want you to verify using one of the
| first two methods first.
| drdaeman wrote:
| This is odd - they sure do support WebAuthn, I've been using a
| YubiKey for years.
| ProZsolt wrote:
| I use FIDO U2F since 2015.
|
| I got my Yubikey from Github for $5
| https://github.blog/2015-10-01-github-supports-universal-2nd...
| mdb31 wrote:
| Yet, if you go into the "enable 2FA" settings on Github, you
| only get the option to enable insecure TOTP or SMS.
|
| Apparently, once you do that, you _might_ be able to add
| proper authentication. But no word on whether that then
| replaces the obsolete methods you were forced to configure
| earlier.
|
| But, yes, right on track to enforce 2FA in 2023, I see...
| pc86 wrote:
| Since when is TOTP obsolete?
| mdb31 wrote:
| > Since when is TOTP obsolete?
|
| Since about the moment that teams all over the world
| discovered they could just paste the enrollment QR code
| (a.k.a. private key) into their wikis, and thereby
| continue unlimited sharing of their role accounts?
|
| So, I guess 30 seconds after its introduction?
| Nzen wrote:
| Github requires [0] the first 2FA mechanism to be totp or
| sms. Thereafter, you can add a webauthn compatible hardware
| key.
|
| [0] https://docs.github.com/en/authentication/securing-
| your-acco...
| roblabla wrote:
| Why though? That makes absolutely no sense.
| procombo wrote:
| Just technically it makes no sense. WebAuthn is a great
| technology that addresses many privacy concerns, but once
| they had an excuse collecting phone numbers they don't
| want to stop. Even though it's not the most secure
| method. Google, and many others are the same way.
|
| 2FA is often used as an excuse to obtain more PII from
| people, and to verify your identity, as a whole. Most
| businesses want to match logins to individuals, not
| roles. And that's what 2FA provides them.
| deadbunny wrote:
| How do they get my phone number from TOTP?
| jotm wrote:
| OK, what's wrong with requiring a _very_ strong password and not
| having any recovery option? If you lost /forgot your password,
| that's it, kiss your account goodbye. It puts the responsibility
| on the user, which is good imo.
|
| I've never lost a password. And the only time I lost a somewhat
| important account (Google) was because of their automated
| recovery system. If I could select "disable account recovery" the
| account would've never been highjacked... OK maybe it would've in
| a few decades when the average PC could bruteforce a 128 bit
| password in a reasonable amount of time and Google disabled rate
| limiting for some reason.
| rascul wrote:
| It's hard to require a strong password. No matter what
| constraints you enforce, you'll always end up with various
| forms of P@ssword1.
| jwilk wrote:
| It's easy: generate high-entropy passwords automatically;
| don't let the users set their own.
| 0xbadcafebee wrote:
| Free services with 2FA are a recipe for problems. You will
| eventually have your phone stop working, you will lose your
| hardware fob, and you will lose your recovery codes that you
| forgot where you hid. There is no paid support, so you get what
| you pay for. Trying to get back into your account, if it's even
| possible, will take a long time and lots of work. If you are
| abroad and need access, you might be screwed. If it's _not_ hard
| to get back into your account at that point, their security
| sucks.
|
| I think we all need to consider the possibility of moving off of
| GitHub, or at least keeping a mirror of everything on another
| provider, and making sure any long-lived services that pull from
| GitHub know the other provider to use. You don't want an account
| lockout to mean you've lost all your work.
| [deleted]
| jpalomaki wrote:
| Having support that is able to resolve 2FA problem creates new
| issues - how to prevent attacker from social engineering their
| way around support to gain access to your account. It's hard to
| verify the identity online, across borders.
|
| IMHO there's no good answers on global scale. Identity should
| be handled on local level. Government already has process for
| issuing me new tokens even if I would loose all my existing
| ways of proving my identity. Local organizations know how to
| verify my identity using those tokens. I already put lots of
| trust on my own bank on this, so maybe they could also manage
| my digital identity.
| throwntoday wrote:
| All great points and very common cases, yet services that force
| 2FA seem completely oblivious to this or just don't care about
| responsible users. In instances where it must be a phone number
| it is obviously for data mining.
|
| It is a lazy way to cater to the lowest common denominator of
| users who will eventually fall for a phishing scam or install
| some keylogger and have their password end up in a dump.
| anonymousCar wrote:
| Had this happen to me in November when Android 12 corrupted my
| pixel 5 and I didn't have backup codes. Altogether it took 2
| months before I was able to access everything again, the last
| thing I got access back to was my Xbox lol
| Am4TIfIsER0ppos wrote:
| 2fa is a scam in part to force them to give up more data and in
| part to try to force people to use a government tracking device.
| Just remember this is Microsoft behind this.
|
| There is nothing wrong with my username and password
| sahkopoyta wrote:
| That is such a strange comment considering that there is
| nothing that requires you to use specifically phone as your 2fa
| provider. For example I'm very happy with my self hosted
| Bitwarden (Vaultwarden).
| mataug wrote:
| > 2fa is a scam in part to force them to give up more data and
| in part to try to force people to use a government tracking
| device. Just remember this is Microsoft behind this.
|
| How is 2FA a scam ? Nowhere in the article is a phone number
| mentioned which is the only potential "government tracking
| device". The second factor can be an authenticator app, or even
| a FIDO device
| Am4TIfIsER0ppos wrote:
| Sometime in the not so distant future
|
| > Those old yubikeys [or similar HW device] have a flaw and
| are weak so we [read: the government] are deprecating them.
| You can change them here for the next year or use your phone
| or install our app.
|
| Further in the future after a few cycles of the above
|
| > Too few people use HW tokens so boot up your spy device now
| to log in.
|
| Maybe it won't be HW flaws maybe it will be software. Maybe
| they'll mandate use of some chrome only feature. Maybe they
| bring out the Xbox authentication drink cans.
| dane-pgp wrote:
| When we all have Neuralink chips in our brains, they will
| be able to read the data from our taste buds to check that
| we are really drinking a genuine can of Doritos(tm)
| Mountain Dew(tm).
| hqball wrote:
| Then I have to trust an app (which can have vulnerabilities)
| or a USB device which can be exchanged for a BAD-USB exploit
| carrier.
|
| That looks like offloading security issues to the user.
|
| Sounds far fetched? If the code repositories are that
| valuable, why wouldn't state actors try to mess with the
| hardware and commit underhanded C or similar?
|
| The repository owners would detect the malicious commit?
| Well, in that case, why do we need 2FA in the first place?
| _Algernon_ wrote:
| How does 2fa force you to give them more data?
| Am4TIfIsER0ppos wrote:
| Usually it ends up being a phone number or an app (on a
| phone). The first is to link to govt id and the second is
| that plus all the spying an app does.
| koolba wrote:
| > Today, only approximately 16.5% of active GitHub users and
| 6.44% of npm users use one or more forms of 2FA.
|
| That's atrociously low. I know it's caveat emptor when it comes
| to FOSS, particularly as the nominal price is usually $0, but
| that really needs to be bumped up for anyone that is publishing
| packages to a public registry.
|
| I hope they both mandate it for NPM and publicly flog^Wflag any
| existing accounts as "2FA Not Enabled" so that users can use that
| information to make their own choices about which dependencies to
| include in their projects.
| jgerrish wrote:
| Mercy me, that's some mighty smart incentive centered design
| you done schemed up.
| svnpenn wrote:
| > flag any existing accounts as "2FA Not Enabled" so that users
| can use that information to make their own choices about which
| dependencies to include in their projects.
|
| Fine, do that. I don't care. Just don't force me to use 2FA if
| I don't want to. I prefer the convenience over the extra
| security. This change removes that choice from everyone.
| deadbunny wrote:
| Have you tried using something like a YubiKey? You literally
| just tap it and you're authenticated. No pulling out your
| phone and typing anything.
| svnpenn wrote:
| I don't want to use 2FA, and I certainly don't want to have
| to buy something to use 2FA. What is hard to understand
| about that?
| deadbunny wrote:
| It sounded like you didn't want the hassle of using TOTP
| from a phone which is most people's complaint when using
| 2FA. I was offering a more user friendly alternative. No
| need for the attitude.
| technion wrote:
| It's actually higher than I expected. I've mandated a lot of
| different contractors use MFA over the years and the fighting
| back has been depressing.
| jesushax wrote:
| Allow me to commit career suicide with my counter argument. My
| laptop random shuts off at least once a day (the screen goes
| freeze, then goes pink, it's an M1 mac if that helps). My phone's
| screen is mostly crunched glass shards, and when I charge it, the
| correct voltage doesn't go through. I think the problem is the
| outlets where I'm living?
|
| Anyway, my own devices _are_ the biggest risk in my threat model.
| Both my laptop (where I 'd store the backup codes for GH MFA) and
| my phone (normal MFA authenticator app) turning into bricks is a
| WAY higher risk than someone stealing my Github password.
|
| I'm not even a part of any orgs, no maintained packages (not on
| the account I use now, anyways). So I could store my backup codes
| on the cloud, but Google is getting fussier every day about 'lack
| of backup device' or whatever.
|
| I could use a one time pad (and just memorize it), and store the
| encrypted backup codes on some kind of decentralized, permanent
| db. So a blockchain. But that costs money, and this is basically
| a venial irrelevant problem that I'm only complaining about to be
| a naysayer on this thread. So let's look for a _free_ solution...
|
| Well, what about... free anonymous blogging solutions! I can
| publish it to a bunch of these. I can use memorable usernames.
| Now, I just have to remember the platform(s, plural, cause one
| platform is still risky, could get the account banned or
| something by doing this, so I'll want to use all the big ones,
| reddit, twitter, and so on), the usernames (which will all be the
| same, to accommodate memorization lol), the 2fa backup code one
| time pad, and of course the password itself. But I could use the
| password _as_ the one time pad to lighten the load. And the
| username could be really easily made memorable.
|
| Yes! How easy is that? Okay, I'm going to try it out. If my
| approach is flawed, feel free to steal my GH account (as you can
| probably ascertain, it's a throwaway GH account, which is the
| only reason I'd be annoyed at having to 2FA for it).
|
| I'll report back to this threat and leave a response to myself
| once I have this set up, in case anyone else is curious.
| jesushax wrote:
| Okay, subreddit created:
| https://www.reddit.com/r/encrypted_gb_codes/
|
| I mispelled gh as gb, but that makes it more memorable (Great
| Britain, world war II spies, the cryptonomicon partially taking
| place in the UK, easy peasy).
|
| Okay, so where was I? Right, the encrypted backup codes! Here
| is the code encrypted = []
| secret_key = input('secret key: ') try:
| for index, character in enumerate(input('secret to encrypt:
| ')): encrypted.append(ord(character) ^
| ord(secret_key[index])) except IndexError:
| print('Your key is not big enough to securely encrypt the
| secret!') print('Go play cryptopals to see why
| using XOR that way would be bad')
| print(''.join(hex(i) for i in encrypted))
|
| Aaand the secret is live on reddit. For redundancy I need to
| plaster this everywhere (hiding it in public key exchanges
| would also be easy!), but this will do for now:
|
| https://www.reddit.com/r/encrypted_gb_codes/comments/uj1fll/...
| Helitio wrote:
| I'm using 2fa for email as well. It made my life more secure.
|
| When I read this announcement I was happy because this means
| 2fa is getting even more known,.accepted and used.
| [deleted]
| cmeacham98 wrote:
| Why not just ... print out or write down the backup codes?
| jesushax wrote:
| 1. Don't own a printer
|
| 2. Don't want my hand to cramp
|
| 3. I'm being silly, everyone should use MFA
| technovader wrote:
| Email it to your wife or someone you trust. It will just
| sit in their archived folder until you have an emergency
| jesushax wrote:
| Since the backups are encrypted with my one time pad, I
| don't need a ton of trust, just reliability that they'll
| send me the encrypted codes. I already have them on the
| subreddit I made in my other comment, buuut, it's always
| nice to have another layer of redundancy, right?
|
| Hey, what's your email address?
| coding123 wrote:
| By 2030 all websites will require 2FA, SSL Client Checks, Real ID
| Verified and a blood pin prick.
| dane-pgp wrote:
| You joke, but device attestation is the next step, and the NSA
| are publicly pushing for it.[0] It's already impossible to get
| a burger from McDonald's using their app if you're using an
| unlocked bootloader.[1]
|
| [0] https://art.tools.ietf.org/id/draft-fedorkow-rats-network-
| de...
|
| [1] https://c.mi.com/thread-3882246-1-0.html
| exabrial wrote:
| I wish my PGP key could be used as a root identity for my 2FA
| keys :/
| _fat_santa wrote:
| Anyone that uses Github day to day at work and for side projects
| should have already enabled it.
|
| When I think of what the "most important" account is to me, my
| Github page is pretty damn close to the top. Mine is currently
| 2FA with an automated script that will scan my Github and back
| everything up to GitLab (at least the "important" projects),
| which is also 2FA'd.
|
| Insane setup to protect data in one account but if I loose access
| it would be beyond a bad day for me.
| cardanome wrote:
| I just use different accounts for work and private stuff.
|
| For me 2FA is super annoying because I run my browsers in
| private mode and I restart them multiple times a day, so I have
| to sign in quite often. It effectively makes it much harder for
| me to keep my privacy.
|
| Not to mention loosing the freedom to log in to my accounts
| from everywhere without needing my devices. Things do get
| stolen/lost/destroyed and that is a more realistic threat for
| me than getting my password stolen.
| WithinReason wrote:
| Am I the only one that thinks that 2FA actually increases the
| probability of losing access to an account? It's only a matter
| of losing the 2nd factor.
| bamboozled wrote:
| Github has alternative recovery methods though too, such as
| 2FA over SMS.
| jwilk wrote:
| Documented here:
|
| https://docs.github.com/en/authentication/securing-your-
| acco...
| Fuzzwah wrote:
| And support can help out as long as you can show that you
| can ssh into a github host using the private key of one of
| the public ssh keys assigned to your account.
| zhfliz wrote:
| easily solved by adding multiple MFA options, e.g. multiple
| security keys.
| deadbunny wrote:
| You can have multiple second factors. I have 2 YubiKeys (one
| on me, one in a safe place) and then I have the standard TOTP
| codes on my phone using Authy.
|
| If I manage to lose my phone, live and backup yubikeys then I
| have recovery codes.
|
| It's going to have to be something pretty drastic to cause me
| to loose all of that.
| johannes1234321 wrote:
| For that there are the revoke code. And the backup phone
| number.
| Biganon wrote:
| Or even better than the one time codes they give you, you
| can simply store the secret itself, on a piece of paper in
| a safe.
| jason0597 wrote:
| What people should do is have a small SD card with all of
| their private keys and passwords stored away safely. This SD
| card should be kept in cold storage (e.g. in a safe where you
| keep personal belongings), and never be accessed unless in
| absolute emergency (lost your YubiKey etc and can't get in
| anywhere, etc.)
| Lifelarper wrote:
| SD cards are horrendous for long term storage. Probably the
| worst medium for such a task.
| adamiscool8 wrote:
| What is the best? Cursory googling suggests SD cards last
| ~decades at normal usage [0], and in this context where
| it's barely accessed, maybe longer?
|
| [0] https://www.sdcard.org/consumers/faq
| 0x073 wrote:
| If you go to bluray.com you probably can read the same
| only for blu-ray.
|
| Better search for a neutral source.
| _whiteCaps_ wrote:
| I wrote some scripts to generate QR codes, then printed
| them to photo paper.
|
| https://github.com/alexjh/gpg-backup/blob/master/Makefile
|
| Back then I thought that QR codes were a bit of a gimmick
| but now I'm way more confident that I'll be able to read
| them in the future.
| rapind wrote:
| Nit pick, but I wanted to point out that backing up your cloud
| data (github) to another cloud (gitlab) is increasing
| (approximately doubling) your attack surface. Good for data
| retention though.
| LordDragonfang wrote:
| This assumes that the "attacks" you're concerned with
| preventing are exfiltration of data, rather than
| mutation/deletion of data.
| kevdev wrote:
| I don't think that's an insane setup at all. Losing access to
| GitHub would be bad for a lot of folks on HN I suspect. My
| GitHub has 2FA with Yubikeys and I am planning to do something
| similar to yours with backing up to a personal Gitea
| instance... once I get around to it.
| bbarnett wrote:
| Meanwhile, some use github once a year to file a bug report
| against an OSS project.
|
| Tiered access would be better here. No commits, repos without
| 2fa.
| Symbiote wrote:
| It's clear in the article's title, subtitle, first
| paragraph and bold quote thing that this does not affect
| someone handling issues and not code.
| sudobash1 wrote:
| The post is talking about 2FA for
|
| > active contributors (for example, those who commit code,
| open or merge pull requests, use Actions, or publish
| packages)
|
| So it may not be required to simply file a bug report.
| sebmellen wrote:
| Would you be able to share the GitHub to GitLab backup script?
| exabrial wrote:
| Get rid of the stupid requirement for SMS or TOTP.
| staticassertion wrote:
| Wonderful news. Supply chain security is a disaster because
| developers won't opt into any kind of security features in the
| majority. Mandating 2FA is the obvious solution, and we'll all be
| radically safer for it.
|
| Glad to see Github pushing this, I hope package repositories
| follow suit!
| dane-pgp wrote:
| This change would certainly have helped against the infamous
| "Gathering weak npm credentials" research[0] from 2017, but I
| think that most recent supply chain security issues (in NPM, at
| least) have been due to: 1) typosquatting, 2) developers
| deliberately adding malicious (or unwanted) code into their own
| packages, and 3) deep transitive dependencies on packages that
| have genuine bugs that lead to vulnerabilities.
|
| It's not clear that this 2FA requirement would fix any of those
| problems, but it could one day allow package management tools
| to flag up when one developer has given/sold control of their
| package over to someone else who has less of a reputation and
| might be malicious, as was the case with the event-stream
| package.[1]
|
| [0] https://github.com/ChALkeR/notes/blob/master/Gathering-
| weak-...
|
| [1] https://www.eweek.com/security/node.js-event-stream-hack-
| exp...
| staticassertion wrote:
| Yes, it definitely does not solve every problem.
| dane-pgp wrote:
| Fortunately no one is claiming that it does solve all
| problems, and I wasn't arguing against that non-claim. My
| point was, what percentage of supply chain issues (since
| that 2017 research) would have been mitigated by this
| policy change?
|
| To be extra clear, I'm not saying "This is a bad policy
| because it only stops some attacks", I'm just trying to get
| a sense of scale for how much this will help and how much
| more work needs to be done.
| aaaaaaaaata wrote:
| Do they have an option for no SMS, just MFA?
| throwntoday wrote:
| 2FA has screwed me over in multiple instances over the years
| across different services.
|
| Realizing one weekend away that I forgot to do a quiz for a uni
| course, trying to login to the course website on my phone and
| then remembering my hardware key is at home in my laptop.
|
| Being forced to add a phone number to secure accounts I could not
| give less of a shit about but have to use for one reason or
| another, coming back months later to login, and realizing it's an
| old number and I'm locked out.
|
| Emailing support in those cases and them just removing the phone
| number or changing it without any additional proof making the 2FA
| utterly useless.
|
| Or emailing support and them asking me to send some drivers
| license or ID, then politely telling them to just delete my
| account because they never had that much info about me anyway.
|
| 2FA is a scourge. Just let me worry about my own security, if I
| care about your service, I won't make my password "asdfghjkl". In
| 99% of cases, that is fine and I have never had an issue.
| cosmiccatnap wrote:
| Meanwhile Spotify and Hulu still dont provide it as an option...
| gernb wrote:
| why do you need 2fa for either of those?
| spookthesunset wrote:
| Do content creators have ask area to manage whatever songs
| they upload to Spotify? I actually don't know! But if they
| do, I could see the need for 2FA on the content creator side.
| adolph wrote:
| I wonder what this will mean for the relatively easy onramp for
| kids through Micro:bit and other tools? Maybe kids aren't
| supposed to directly access GitHub?
| gernb wrote:
| I wish they'd let me stay logged in longer. I use about 9
| machines. On each machine I use 2-3 browsers. On some of those
| browsers I have several profiles. GitHub logs me out if I haven't
| used it in about 2 weeks. The result is I have to login with 2FA
| almost daily. it's super annoying
| waynesonfire wrote:
| bank sites do this too.. but they log you out after like 10
| minutes of inactivity. The other day I was thinking of
| installing a plugin for firefox that will refresh a tab
| periodically. Not sure if that'll help the issue but worth a
| try.
| Decabytes wrote:
| I feel like with the recent hackings done by Lapsus, it shows
| that 2FA can actually make it easier to break into a system.
| Since they first break into telecom companies, they can then sim
| swap and reset peoples passwords.
| asimops wrote:
| Using phone numbers as a second factor should be in line with
| using MD5 for password hashing. It doesn't mean that MFA (or
| hashing) are a bad idea, just that you need to deploy it
| properly for it to make a difference.
| Apreche wrote:
| That's because SMS is not 2FA. Proper 2FA implementation should
| require FIDO, TOTP, etc. and not even permit SMS as a valid
| method.
| MattPalmer1086 wrote:
| Nitpicking, but it absolutely _is_ 2FA. Two factors for
| authentication. Password (something you know) and phone
| (something you have).
|
| It's not good 2fa, but it is 2fa.
| tomjen3 wrote:
| SMS should not be considered a 2fa, TOTP or a youbikey is the
| minimum that you should be able to advertise as 2fa.
| chrismorgan wrote:
| You're talking about a completely different thing, SMS for
| password reset. That's _completely_ distinct from SMS as a
| second factor for logging in, which is absolutely fine for
| almost all people's threat models, even in places where SIM or
| telco attacks are feasible, since the SIM alone is insufficient
| to log in as you.
|
| Sure, it's common for sites to use your phone number both for
| 2FA and account recovery (whether single- or multi-factor--and
| single-factor account recovery is obviously a serious problem
| in a two-factor authentication environment), but the problem
| you're complaining about is _nothing_ to do with 2FA.
|
| I think Fastmail hits the right balance, and explains it well:
| https://www.fastmail.help/hc/en-
| us/articles/360058752374-Usi..., heading "Why do I have to add
| a recovery phone number to set up two-step verification?"
| MattPalmer1086 wrote:
| If an attacker can get a SIM for your number, SMS 2fa is
| useless. They will get the second factor by text message just
| as you would.
| jeromegv wrote:
| But they need your password first. So you're not in a worse
| position than if you didn't have 2FA. Parent was implying
| 2FA made it worse.
| blfr wrote:
| It's not useless. It forces the attacker to expand all the
| effort to get a SIM for your number. While certainly
| possible, it's not _that_ easy.
| MattPalmer1086 wrote:
| I said it's useless _if_ an attacker can get access to a
| SIM (or hack the SS7 protocol, or whatever).
|
| Clearly it's an extra bar for an attacker, no
| disagreement there.
| chrismorgan wrote:
| They still need your password. The SMS alone is
| insufficient. Supporting SMS as a second factor (whether
| primary or backup) is perfectly adequate for almost
| everyone's threat model, and generally far superior to
| _not_ supporting it as regards avoiding account lockout.
| (That's Fastmail's position, which I thoroughly agree
| with.)
| MattPalmer1086 wrote:
| I agree it's probably better than nothing for many
| people.
|
| It's still pretty much the worst form of 2fa there is,
| and not nearly as secure as people assume.
| Hamuko wrote:
| Easier than what? Not having any 2FA at all?
|
| I don't really understand how it can be easier to break into a
| system if you need the username, the password and an SMS code,
| than if you just need an username and a password.
|
| Obviously, SMS two-factor authentication is flawed. But one-
| time codes and WebAuthn are pretty good two-factor
| authentication methods to secure important credentials.
| svnpenn wrote:
| Don't they already offer a 2FA option now? Why not just let
| people use it who want to, and leave everyone else alone?
|
| I am an adult. If I want to sacrifice some security in the name
| of convenience, I should have that option. All this is doing, is
| pissing me off, and giving me one more reason to move to another
| platform.
| rapind wrote:
| I think a good compromise is to allow organizations to opt to
| require 2FA in order to access their repositories, and allow
| individuals to opt to require 2FA for write permissions in
| their repositories (public or private).
| diablerouge wrote:
| The organizational control is already the case :) I had to
| set it up when I was added to my work's GitHub org.
| dimensionc132 wrote:
| AtNightWeCode wrote:
| 425% cost increase to enable SSO on Github. Just saying.
| [deleted]
| spookthesunset wrote:
| The only places that want SSO will be larger enterprises who
| don't have a problem paying $$$ for an enterprise package.
| Tying SSO to enterprise plans is a great way to segment your
| market!
| AtNightWeCode wrote:
| Having a central way of managing who has access to a repo is
| an enterprise feature? I call bullshit on this.
| sebmellen wrote:
| So ridiculous. Really hurts for smaller startups.
| mbesto wrote:
| If you're small then the benefits of SSO aren't really there
| anyway. When you're a team of 10, what benefit is SSO really
| giving?
| orphean wrote:
| I work in a small company and we have to have SSO for
| compliance reasons (SOC II, HIPAA, NIST, etc)
|
| It's dumb but without it trying to tick all the compliance
| boxes is much more annoying.
| AtNightWeCode wrote:
| You go through a review, and somebody asks who this guy
| xxx123 is that made this change, and somebody vaguely
| recalls it is some consultant that for some reason still
| have access to everything but quit two years ago. Love
| those meetings.
| sebmellen wrote:
| Unfortunately this is not true when you're trying to
| undergo a SOC 2 audit.
| mbesto wrote:
| First, there is no requirement by SOC2 that says you
| "must use SSO for all applications". SOC2 talks about
| "logical access controls". For a team of 10, you would
| simply have a policy that states "any time a new
| developer comes on, they have to use MFA to access GitHub
| and this is enforced because we check the box in GH, blah
| blah" and "any time a developer leaves the company, we
| revoke all access, blah blah".
|
| Also, if you're going to spend $20k+ on SOC2 because your
| clients require it, then spending the $20k on GitHub
| shouldn't be a problem because your clients should be
| paying for it (i.e. your ACV should be high enough to
| cover these things).
| sebmellen wrote:
| Yes, but SSO makes writing those policies (across all
| apps) much simpler. I think it's too bad that SSO is so
| heavily taxed, because it's quite an elegant way to solve
| account provisioning.
|
| Interesting site: https://sso.tax/
| sonicggg wrote:
| Let's just remind ourselves that we're not born with attached
| cellphones. These things get broken, lost, stolen, etc. Besides,
| some people do not own one. How will they solve the problem of
| folks getting locked out? And if anyone says there is a
| workaround for cases like this, then what problem is it solving?
| jedberg wrote:
| Authy synchronizes across devices and works on a computer. If
| you're using Github then you at least have a computer. And
| using 2FA on your own computer at least guarantees that the
| access is from your computer.
|
| Sure, someone could hack your computer and get access to your
| GitHub, but if they're already on your computer, they can just
| change the code and do a git push too.
| fs111 wrote:
| github will give you backup codes you can print out and use in
| case somthing bad happens.
|
| I personally have 2 yubikeys registered as the second factor
| and it works great. They last years w/o any problem.
| protomyth wrote:
| We had to buy yubikeys for various things since the whole
| cellphone thing wasn't going to work. You do have to buy
| multiple because of breakage or loss.
| cesarb wrote:
| > github will give you backup codes you can print out and use
| in case somthing bad happens.
|
| The backup codes have a "nearly never used" issue: since
| they're nearly never used, it's easy to forget where you put
| that piece of paper (I vaguely know where mine might be
| located, but I'd have to lose some time searching for it if I
| ever needed it).
|
| And there's also the risk that the "something bad" affects
| both the TOTP device and the backup codes. If your home is
| flooded, for instance, you might lose to water damage both
| the piece of paper where the backup codes are _and_ your
| mobile phone.
| mfer wrote:
| I think you bring up a great point. How can people do 2FA well
| for their situations? This is a practical question and people
| make many assumptions. A lot of what I know isn't clearly
| documented.
|
| Clearly communicating a bunch of different options would be
| helpful for people.
|
| Personally, I have 2 yubikeys, Authy synced to multiple
| devices, and the backup codes. There a bunch of options with
| different tradeoffs.
| dotnet00 wrote:
| They provide a set of single use recovery codes for that
| purpose. I keep an encrypted copy of them in cloud storage and
| in several physical backups, so in the event that I lose or
| don't have access to neither my main nor backup yubikey, I can
| very likely still dig up a recovery code (eg by calling up a
| relative and asking them to read me the code).
| kmlx wrote:
| > Let's just remind ourselves that we're not born with attached
| cellphones.
|
| 2FA doesn't mean only SMS or smartphone app.
| banana_giraffe wrote:
| The provide 16 single use codes for the "my TOPT device blew
| up" case, enough to get you in and reset things.
|
| And for people that are unable or refuse to use a secondary
| device, there's no technical reason you can't run a TOPT app on
| your desktop.
| em-bee wrote:
| i am only using github infrequently. the risk of getting locked
| out scares me. the likelihood of me forgetting which device i
| used to enable 2FA and maybe breaking/loosing/reinstalling said
| device (while forgetting to back up the 2FA to another device,
| and never mind remembering where i put the backup codes that
| were created 10 years ago) is much greater than anyone breaking
| into my account.
|
| the end result will be that i won't be contributing code on
| github anymore but rather copy the project elsewhere and tell
| the developers where to pull my patches from.
| _Algernon_ wrote:
| Worst case you'd have to download new one time codes every
| tenth login or something like that.
| throwntoday wrote:
| Yeah I can't see how it could be any worse than that.
| _Algernon_ wrote:
| Writing down a single new one time code after each login?
| WhyNotHugo wrote:
| You can buy a couple of Yubikeys, and use one as backup.
|
| Probably feasible for most users of HN, but prohibitively
| expensive for millions around the world. Using a phone for 2FA
| is not great:
|
| 1. You can lose it. 2. If you're backing up 2FA to the cloud,
| then it's not 2FA any more. 3. If you use a password manager on
| your phone, then both factors are the same, it's not really
| 2FA.
| mattacular wrote:
| If you backup 2FA to the cloud (eg. authy) how does that not
| count as a second factor still even if security is diminished
| for other reasons?
| kayodelycaon wrote:
| This does not solve the problem of losing or breaking the
| device containing the key.
|
| And it significantly degrades the user experience by
| requiring you have both devices available when you create an
| account to have any kind of backup.
| abetusk wrote:
| I appreciate that there's a response to the 'supply chain attack'
| issue, but this also seems like we're raising the bar further for
| participation. I'm still dubious as to whether a phone is
| required but even if it's not, this now puts a high bar for
| anyone who doesn't have a phone and creates all sorts of
| anonymity issues for people that do.
|
| Git is decentralized. My feeling is we should be focusing on
| technologies that lean into that idea.
|
| Inter-Planetary Version Control [0] looks to be a defunct project
| but hits the keywords that fit what I imagine to be a viable
| alternative. Does anyone know other alternatives?
|
| [0] https://github.com/martindbp/ipvc
| throwaway92394 wrote:
| There isn't be a need for a phone. TOTP (time based one time
| passwords) which Github supports is just an algorithm, you can
| (and many password managers have it too) run TOTP on the
| desktop.
|
| Whether this is a good idea or not is up for debate, but it
| doesn't require a phone, or even internet technically, just an
| accurate (within ~1 minute) time.
|
| EDIT: Typo should -> shouldn't
|
| EDIT2: to be more clear- shouldn't -> isn't
| rsync wrote:
| Show me a TOTP implementation that doesn't require a phone
| number to sign up for or initialize...
|
| IME, they not only require a phone number at setup but,
| further, reject VOIP/twilio numbers.
|
| This shows that it's not at all about security, but about
| slowing (but not solving) their brutal, unrelenting, spam and
| sock puppet problems.
|
| EDIT: Thanks - very interesting. I guess I am jaded by my
| experiences with 'authy' and twilio, etc.
| roblabla wrote:
| TOTP never requires a phone number. On GitHub, they either
| show you a qr code you can scan in an app, or a text you
| can import. All apps support this sign up process, from
| google authenticator to console-based tools like totp[0].
|
| Other 2FA implementations may require phone numbers. But
| HOTP and TOTP don't.
|
| [0]: https://github.com/arcanericky/totp
| vel0city wrote:
| Well, for starters, Github. I don't have a phone number on
| file with them and I have TOTP and FIDO available.
|
| The vast majority of sites I use TOTP on didn't require a
| phone number for the account.
| dane-pgp wrote:
| > There isn't be a need for a phone.
|
| You might need an "EDIT3", I'm afraid, because "isn't be"
| doesn't make that sentence much more clear.
| abetusk wrote:
| Can you provide some more context? In theory TOTP doesn't
| need a mobile phone (I guess) but in practice this is about
| whether GitHub, or anyone else, provides non-mobile 2FA
| options, either as an app running on the phone or by
| receiving a text message, say.
|
| See https://docs.github.com/en/authentication/securing-your-
| acco... . I've only skimmed but I don't see anything in that
| list that doesn't require a mobile phone in one form or
| another.
| vel0city wrote:
| You should try reading it instead of just skimming it.
| Their steps for using TOTP (the first list of steps!) do
| not say _anything_ about putting in a mobile phone or list
| _any_ requirements about adding a mobile phone.
|
| Then at the bottom for using a security key, it says "You
| must have already configured 2FA via a TOTP mobile app or
| via SMS". A TOTP app _does not_ give out your phone number,
| _does not_ rely on network connectivity, and _does not_
| require you use a mobile phone to use.
|
| So 2/3 of the options _absolutely do not_ require you give
| Google your phone number.
| abetusk wrote:
| The answer is that many of the applications listed under
| "mobile apps" have a desktop version that one can use. I
| did only skim but doing a little more link diving on the
| prompting of other siblings comments in this thread shows
| that most of those programs have desktop versions.
|
| Your comment would leave the reader confused, including
| myself had I not dug deeper into each of those links,
| because you don't address the fundamental issue. The
| GitHub page says "mobile app" even though many of the
| applications can be installed on desktop.
|
| The line "You must have already configured 2FA via a TOTP
| mobile app or via SMS" further confuses the issue because
| this implies anyone wanting to use 2FA would need a
| mobile phone, which was precisely my point. A TOTP that
| doesn't give out your phone number, but still requires a
| mobile phone to use, technically doesn't need a working
| phone to use but practically does require a phone, so
| it's a kind of pedantic point you're making.
|
| Phones are a huge attack surface, if not from scammers
| then from applications, businesses or governments wanting
| to use it to monitor usage.
| vel0city wrote:
| > implies anyone wanting to use 2FA would need a mobile
| phone
|
| I will acknowledge they probably shouldn't use the
| terminology "mobile app", but the most common way for
| people to use TOTP _is_ with a mobile app which does
| TOTP. FWIW, there are many ways you can run a "mobile
| app" without using your primary phone, tablets also run
| "mobile apps" and there are tools to run such apps on
| your computer locally. This doesn't in any way give the
| service any kind of connectivity or access or tracking of
| your phone, and TOTP does not use any kind of network
| connectivity to operate.
|
| I'll agree the above is a pedantic point to be making,
| and I agree their documentation could be better worded,
| and I can understand there being a bit of confusion.
| However whether or not you need to use a mobile phone, if
| the solution is TOTP a la Google Authenticator/Microsoft
| Authenticator/LastPass/Authy/1Password (RFC 6238), the
| answer is _always_ no. RFC 6238 does not require phone
| numbers, it does not require network access, its purely
| hashes on the current time and an initial shared secret.
|
| https://www.rfc-editor.org/rfc/rfc6238
| SahAssar wrote:
| I use TOTP on my desktop via a hardware key. There are many
| ways to do 2fa without phones as long as the provider does
| not consider 2fa to equal sms.
| abraham wrote:
| #1 says TOTP mobile app but any desktop app would work.
| akerl_ wrote:
| 1Password is in that list.
| davchana wrote:
| Yes,all good points. Many vanilla javascript scripts are
| available to get this TOTP. The service provider can increase
| this 30 seconds (technically not, they just accept any 1
| current time token = 30 seconds, any 3 token, 1 past, 1
| current, 1 next = 90 seconds, and any number of past present
| tokens) to any multiple of 30 seconds. My personal scripts
| use 3 minutes.
| mzs wrote:
| How do I actually do this? I want to keep using ssh. I don't have
| and don't want a cellphone. I use FreeBSD. I can't find a simple
| explanation in the docs.
| scrollaway wrote:
| Use any password manager (you should already be using one) that
| has TOTP support such as keepassxc or 1Password. No cellphone
| needed.
| mzs wrote:
| I use a key-pair for github ssh. I don't use any password
| managers, instead I have unique long passwords. What's my
| second factor without a cellphone?
| potatoz2 wrote:
| I don't believe this 2FA announcement applies to SSH
| access. The public key you use is already 2FA enabled, in a
| sense (the key is what you have, the password to unlock it
| what you know).
|
| This applies to logging in to the GitHub Web application.
| TimWolla wrote:
| You can use OATHTOOL [1] on the command line or even roll
| your own TOTP implementation [2] in just a few lines of
| code in your favorite programming language.
|
| [1] https://www.nongnu.org/oath-toolkit/oathtool.1.html [2]
| https://datatracker.ietf.org/doc/html/rfc6238
| throwntoday wrote:
| Why should someone be using a password manager? Generating
| needlessly complex, unique passwords for each service seems
| like a good way to lock yourself out of your own accounts in
| an emergency.
|
| Laptop or phone stolen? No access to your own devices? Oops
| guess you can't login to anything.
| tomjen3 wrote:
| That is a scenario that is a lot less likely than some
| service having losing control over your password. If you
| are concerned about it, you can always write down the
| password into a physical notebook.
| technovader wrote:
| because it makes your passwords significantly less likely
| to be guessed
| throwntoday wrote:
| I don't know of a single competent service that allows
| you to just guess passwords more than a few times.
| butz wrote:
| Are there any downsides to security keys as 2FA? Are they using a
| single standard that shouldn't accidentally change or be
| deprecated for some reason? Is it possible to use them on mobile
| devices? Are there any risks they might break? Any issues with
| Linux support? Which particular security key would you recommend
| and why?
| mzs wrote:
| I don't have a cellphone or usb dongle and don't want them.
| jrochkind1 wrote:
| As far as complying with 2FA requirements without these, if
| TOTP is an option, one way is to use Authy with desktop
| client. It's free.
|
| How secure it is I can't really say. But it will allow you to
| access services requiring TOTP without a cellphone or usb
| dongle.
|
| https://authy.com/blog/introducing-authy-for-your-
| personal-c...
| eulers_secret wrote:
| If you're as crazy as I am, it looks like oauthtool+gnupg2
| can do TOTP via the command-line on Linux as well. I think
| it's just another function that my homeserver will take
| over (or maybe a container). At least I can easily
| integrate this new info into my backup system, unlike apps
| on my phone...
| waynesonfire wrote:
| you can get a tiny one and keep it plugged into your laptop
| mzs wrote:
| Okay so which one do I buy and how do I use it with ssh.
| The documentation is not specific.
| saltcured wrote:
| The github.com documentation pages I read on this topic
| yesterday said the MFA requirement was for web sign-on
| and https GIT repo URLs. It explicitly said that SSH-
| based git repo access would not be affected. Has anyone
| seen contradictory statements published by github?
|
| Edit to add: I mean SSH git access using a keypair
| registered with your account. (I don't know if there is
| some legacy option to use SSH with passwords, which I
| imagine would be discontinued if not already.)
| waynesonfire wrote:
| yubikey 5 nano, get two. i use it w/ ssh. took a little
| googling to integrate the gpg authentications key w/ ssh.
| instead of using ssh-agent, you'd use gpg-agent to manage
| the keys.
|
| there are other integrations, for example, i can also
| unlock my mac w/ the yubikey.
| newjersey wrote:
| On gnome on fedora at least, I can have my gpg
| automatically unlock when I login to the desktop.
|
| I already have two steps on GitHub with the authy app but
| I don't get it. Why is it not good enough to send an
| email with a code when signing in without a cookie for
| people who don't want to opt in to two steps?
|
| The way I see it my authy is a vulnerability because if
| someone were to guess my authy phone number, they could
| technically grab all of my TOTP.
|
| I don't get this spoon feeding. I mean I would sign up to
| two steps where I can but something doesn't feel right
| about the lack of choice.
| waynesonfire wrote:
| i hate checking email or looking at my phone for two step
| auth. either choice requires me to access another system.
| It requires far fewer steps to just tap the button on the
| side of the yubikey.
| mzs wrote:
| It's pricey but looks like it won't be too warty, thanks.
|
| https://forums.freebsd.org/threads/yubikey-5-nfc-not-
| working...
| newjersey wrote:
| > Okay so which one do I buy and how do I use it with
| ssh. The documentation is not specific.
|
| Oh crap, I was thinking this doesn't affect me because I
| already have two factors authentication but yes if I need
| to fish out my phone every time I need to git something
| (I use sash, not tokens) that requires authentication, I
| will definitely minimize what I do on GitHub.
| sdfgdfgbsdfg wrote:
| For security keys implementing FIDO (which sometimes you can
| see referred to as WebAuthn, although that is partially
| inaccurate), there is currently no good way of backing up the
| key. If you lose it, then you'll need to recover your account
| with every service you had it registed it with, meaning that
| you'll need at least an additional factor on each service
| that's most likely not as secure as a FIDO key, unless you're
| registering two keys for every service which is very cumbersome
| and still makes you re register a lost key with each service.
|
| There are proposals to address this either by chaining trust
| between security keys or by sharing "passkeys" (a webauthn
| credential). see https://news.ycombinator.com/item?id=31272867
| Only apple implements it today as far as I know so there's no
| good way to recover from a lost or damaged key if you're not
| exclusively in the apple ecosystem
| otachack wrote:
| Not that I know of, but you should definitely at least enable a
| second form of 2FA like the recovery codes OR a second security
| key, then print/write/store the file/key somewhere. If you lose
| your primary, then you can use that secondary. Never just have
| 1 form of 2FA without a fallback.
| manquer wrote:
| I have used various products from yubikey they work well on
| both Linux and Mac and you can also store gpg keys on them for
| commit signing and so on
|
| Install experience is not the best , but drivers work well
| tedunangst wrote:
| Except it's not actually 2FA if all it takes is an ssh key to
| push. That's only one factor. Doesn't address the threat model of
| compromised developer machine.
| svnpenn wrote:
| Please, don't give them any more "good" ideas.
| newjersey wrote:
| Yes, if I need to fish out my phone and put in a code every
| time I need to git fetch a private repo, I will do everything
| I can to convince anyone who will listen away from GitHub
| deadbunny wrote:
| Derive you SSH key from a GPG key stored on a YubiKey[1] and
| even if you comprise the machine you don't get the keys.
|
| 1. https://github.com/drduh/YubiKey-Guide
| potatoz2 wrote:
| If your SSH key is encrypted, it's 2FA.
|
| Either way, it's not phishable (unlike passwords) so it's way
| safer.
| aseipp wrote:
| But it's significantly easier, like way way easier, to phish
| someone versus compromise a filesystem and extract SSH keys.
| And you can just add keys afterwords if you phish them, so why
| wouldn't you go the easy route? That's why phishing is still
| such a massive problem: because it works.
| blippage wrote:
| Can anyone ELI5?
|
| It seems that I will requires either SMS, a mobile app, or USB
| dongle. I'm not happy about any of these options. I'm not going
| to give away my phone number, I don't have a smartphone (I have a
| Nexus from 2012 though), and I don't want to fork out on dongles.
|
| Someone mentioned that keepassx being able to do it, but I'm a
| bit hazy on that.
|
| I've registered for a gitlab account just now, and I'll be
| messing around with that for awhile to see if I like it. If it
| proves tolerable, I'll probably be yanking the plug on github.
| jwilk wrote:
| TOTP is one of the supported 2FA method. There's a lot of TOTP
| implementations that don't require having a separate device.
| And if you're not happy with any of them, this is such a simple
| protocol, you can write your own in one evening.
| Longhanks wrote:
| > At GitHub, we believe that our unique position as the home for
| all developers means that we have both an opportunity and a
| responsibility to raise the bar for security across the software
| development ecosystem.
|
| The fact that GitHub assumes to be in this position is alarming.
| Combined with this enforcement which I do not appreciate, I'm
| reconsidering my investment and will actively start migrating off
| of GitHub.
| LudwigNagasena wrote:
| I hate those paternalistic ethics. Your responsibility is not
| to get hacked. My responsibility is to make sure I don't leak
| my credentials. Telling people how to live is _not_ your
| responsibility.
| kmlx wrote:
| > The fact that GitHub assumes to be in this position is
| alarming.
|
| it's kind of true, isn't it (for certain programming
| languages)?
| staticassertion wrote:
| jacobsenscott wrote:
| totp on gh doesn't "secure your dependencies" in any
| meaningful way though. For example npm and rubygems and
| dockerhub, and pretty much any other library packaging system
| don't pull code from gh, so the code on gh doesn't need to
| match the code in the library you are actually installing and
| running.
|
| git secures itself. You can't "sneak" malicious code into a
| library if you can log into a dev's gh account. All you can
| do is add commits. It would be an obvious commit and the dev
| wouldn't push it to their package host.
| zmgsabst wrote:
| > so if people like you, who don't care about that, select
| yourselves out - perfect!
|
| This is an ad hominem.
|
| You don't know anything about security measures they do or do
| not take -- just that they don't appreciate a vendor
| mandating their security policy from a position of presumed
| authority.
|
| That kind of bad faith comment isn't constructive.
| Arnavion wrote:
| >just that they don't appreciate a vendor mandating their
| security policy from a position of presumed authority.
|
| The account is with the vendor in question. The vendor is
| literally the only entity in a position of authority.
| zmgsabst wrote:
| Can you name another example of a major vendor demanding
| policy from its customers?
| akerl_ wrote:
| https://antivirus.com/2021/11/25/google-is-making-2fa-
| mandat...
|
| https://techcrunch.com/2021/12/02/facebook-two-factor-
| mandat...
|
| https://www.wsj.com/articles/tech-companies-push-users-
| to-ad...
|
| https://www.twilio.com/blog/mandatory-2fa-account-login
| ipaddr wrote:
| How is this a win for you? Now you can blindly trust any
| github account now that they are 2fa to update their
| dependencies? That assumption doesn't make sense.
|
| First the dependencies don't have to live on github or they
| could have been added by a non 2fa before this change
|
| This is going to lock many out causing fewer packages to be
| updated meaning things are less trustworthy on github
|
| People who use 2fa are not related to the same group who
| updates their dependencies
| deadbunny wrote:
| How is enforced 2FA going to "lock people out" of
| coding/updating packages?
| natly wrote:
| A nicer tone wouldn't hurt.
| staticassertion wrote:
| I don't see what's mean about what I said, I'm quite
| excited to see this change already having positive impact.
| tarboreus wrote:
| Going to second that your tone is a bit on the snooty
| side.
|
| I'll go ahead and join OP and "self-select" my way out of
| the all-encompassing developer community that GitHub
| represents, leaving you pro coders to it. Enjoy the walls
| around your garden.
| staticassertion wrote:
| Excellent stuff :)
| pc86 wrote:
| I have a hard time believing that you're unintentionally
| being an asshole in this thread, it's so on the nose that
| I have to believe it's on purpose.
| staticassertion wrote:
| I'm just celebrating a successful deployment of something
| I've wanted for a long time. It's already being effective
| and it's not even rolled out yet.
| natly wrote:
| You know full well that your tone from the perspective of
| the person you responded to is very harsh, please try to
| be more respectful.
| staticassertion wrote:
| I wouldn't classify it as very harsh at all.
| JJAcedL wrote:
| I mean... they are the default home for most open source
___________________________________________________________________
(page generated 2022-05-05 23:02 UTC)