GitHub Will Require All Code Contributors To Use 2FA (theverge.com) 100
GitHub, the code hosting platform used by tens of millions of software developers around the world, announced today that all users who upload code to the site will need to enable one or more forms of two-factor authentication (2FA) by the end of 2023 in order to continue using the platform. The Verge reports: The new policy was announced Wednesday in a blog post by GitHub's chief security officer (CSO) Mike Hanley, which highlighted the Microsoft-owned platform's role in protecting the integrity of the software development process in the face of threats created by bad actors taking over developers' accounts. "The software supply chain starts with the developer," Hanley wrote. "Developer accounts are frequent targets for social engineering and account takeover, and protecting developers from these types of attacks is the first and most critical step toward securing the supply chain."
Even though multi-factor authentication provides significant additional protection to online accounts, GitHub's internal research shows that only around 16.5 percent of active users (roughly one in six) currently enable the enhanced security measures on their accounts -- a surprisingly low figure given that the platform's user base should be aware of the risks of password-only protection. By steering these users towards a higher minimum standard of account protection, GitHub hopes to boost the overall security of the software development community as a whole, Hanley told The Verge. "GitHub is in a unique position here, just by virtue of the vast majority of open source and creator communities living on GitHub.com, that we can have a significant positive impact on the security of the overall ecosystem by raising the bar from a security hygiene perspective," Hanley said. "We feel like it's really one of the best ecosystem-wide benefits that we can provide, and we're committed to making sure that we work through any of the challenges or obstacles to making sure that there's successful adoption."
Even though multi-factor authentication provides significant additional protection to online accounts, GitHub's internal research shows that only around 16.5 percent of active users (roughly one in six) currently enable the enhanced security measures on their accounts -- a surprisingly low figure given that the platform's user base should be aware of the risks of password-only protection. By steering these users towards a higher minimum standard of account protection, GitHub hopes to boost the overall security of the software development community as a whole, Hanley told The Verge. "GitHub is in a unique position here, just by virtue of the vast majority of open source and creator communities living on GitHub.com, that we can have a significant positive impact on the security of the overall ecosystem by raising the bar from a security hygiene perspective," Hanley said. "We feel like it's really one of the best ecosystem-wide benefits that we can provide, and we're committed to making sure that we work through any of the challenges or obstacles to making sure that there's successful adoption."
As long as it supports anonymous auth. (Score:5, Insightful)
I'm okay with it as long as I can use a standalone OTP app and not SMS messages or any other method which ties my account to a real identity.
Re: (Score:2)
If you logged into github you could see it supports TOTP, so you can use any compatible app or even write your own (it's a small shell script).
Re: (Score:2)
>you could see it supports TOTP
Top Of The Pops was a great show. All should support it.
Re:As long as it supports anonymous auth. (Score:4, Informative)
Not only does Github support TOTP, it also supports WebAuthn [webauthn.io], which means your YubiKey [yubico.com] will work out of the box.
Re: (Score:1, Troll)
Re: (Score:3)
You can. I have the app as a backup in case I ever have an issue with my key.
By the way, I wish more laptops had NFC readers. I can just tap the key, rather than needing to plug it in. Aside from anything else, we still have to deal with a mixture of USB A and C ports. For desktop I got a USB NFC reader and stuck it to the underside of my desk.
How are service accounts going to work? (Score:2)
Re: How are service accounts going to work? (Score:2)
app passwords like in intellij / other tools for u (Score:2)
app passwords like in intellij / other tools for user accounts.
In git pipelines have there auth builtin
Re: (Score:2)
SSH keys are unaffected. API keys are also likely unaffected. 2FA is currently only available for the main GitHub web interface. So unless you are using the GitHub login interface and web scraping GitHub as a signed in user (why?) I doubt there will be a problem.
Worst case scenario: Exfiltrate session cookies from your web browser to a non-expiring cookie store.
Re: (Score:2)
2FA is currently only available for the main GitHub web interface. So unless you are using the GitHub login interface and web scraping GitHub as a signed in user (why?) I doubt there will be a problem.
Last I checked, GitHub users used the web interface to submit and act on pull requests.
Re: (Score:2)
It hasn't come up for me as a 2FA user, however, if it did insert itself in some automation flow, you could take the OTP secret and just replicate the logic to generate the code.
TOTP is a fairly straightforward shared secret scheme.
However, the main point of TOTP is to make machine generated keying material practical for human interaction. API keys and ssh keys are already good enough so as not to require something like it to make it credible.
baby, bathwater. goose, golden egg. (Score:3, Informative)
Perhaps github should interpret this to mean that 83.5% of their users DO NOT WANT to deal with 2fa. They are shooting themselves in the foot with this, and I for one will migrate elsewhere the second they require it, if not before.
Re: (Score:2)
I think it's more likely 83.5% of their users haven't logged in in the last couple years.
The two factor authentication works pretty well. They support TOTP instead of insisting on texting you.
Re: (Score:3)
I don't want it, and will leave if they insist. If I am overseas I don't pay roaming charges so I don't have a phone. What if I loose my phone or leave it at home, unlike most people I am not attached to it.
Re: (Score:2)
TOTP does not require any data transfer, so there are no roaming charges. (It just requires that your phone's clock be reasonably well synchronized with the servers' clocks.)
2FA is the wave of the future. Eventually, all serious Web platforms will require it, so you might as well get used to it, and also lobby for sensible things like TOTP instead of broken things like sending codes via email or SMS.
Re: (Score:3)
TOTP does not require any data transfer, so there are no roaming charges. (It just requires that your phone's clock be reasonably well synchronized with the servers' clocks.)
TOTP is both insecure and painful to use.
2FA is the wave of the future. Eventually, all serious Web platforms will require it, so you might as well get used to it, and also lobby for sensible things like TOTP instead of broken things like sending codes via email or SMS.
TOTP and SMS are insecure and only represent ancient history. This is dead end technology with no future whatsoever.
Client certificates have been around for nearly two decades now, are universally supported and easy to use.
Unlike either TOTP or SMS they completely protect against phishing attacks which is a top threat to online security.
Re: (Score:2)
Github supports using security keys, which provide the benefits of public key crypto and phishing resistance that client certificates have without having to deal with installation and expiration of client certificates. Many devices such as phones and laptops have the capability built-in now.
Re: (Score:2)
Github supports using security keys, which provide the benefits of public key crypto and phishing resistance that client certificates have without having to deal with installation and expiration of client certificates.
Client certs are the same concept as security keys. Instead of private key stored in a USB stick (Requiring USB is poor security) it can either be stored in the clients key store or on external smartcard. The import of new PKCS12 files is simple and expiration is server controlled. Personally I use a 15 year validity period.
Many devices such as phones and laptops have the capability built-in now.
The same devices had client certs capability for many years. This is existing technology that has been widely deployed in corporate settings.
Re: (Score:2)
Client certificates have been around for nearly two decades now, are universally supported and easy to use.
Client certificates only work if you have control over the client. Which I usually do not have.
But I guess it is time to buy a dedicated mini home server and set that up as my "code sharing platform".
Re: (Score:2)
Client certificates only work if you have control over the client. Which I usually do not have.
Even when using a shared workstation they can still be used because the certs are linked to your computer account or you can use a smartcard reader for portability.
Re: (Score:2)
Yes: and I can not install a client certificate. Nor can I plug in a smart reader, and neither is a client certificate connected to the workstation. It is connected TO THE LOGGED IN USER!
Ooops.
Re: (Score:2)
TOTP has valuable because it's so easy to implement, take any old computing device with a screen and you could credibly get TOTP to it. If a provider only allows one 'device' as an OTP provider, at least with TOTP I'm empowered to replicate it according to my needs. Yes, asymmetric encryption further protects against someone phishing the code, but server certificates and knowing never to use the code on a phone conversation eliminates the phishing risk.
Client certificates are not universally supported. Ver
Re: (Score:2)
TOTP has valuable because it's so easy to implement, take any old computing device with a screen and you could credibly get TOTP to it. If a provider only allows one 'device' as an OTP provider, at least with TOTP I'm empowered to replicate it according to my needs. Yes, asymmetric encryption further protects against someone phishing the code, but server certificates and knowing never to use the code on a phone conversation eliminates the phishing risk.
It's now 2022. The time for TOTP to have had value was in the late 90s. Today the largest threat to online security is phishing to which TOTP offers no protection whatsoever. Being simple to implement does not excuse the fact that you are constantly bugging the end user to enter codes in a limited window of time. This is not user friendly and it is not secure.
"Never to use the code on a phone conversation eliminates the phishing risk" is unfortunately without merit.
Client certificates are not universally supported. Very few things bothered to support them
They are with few exceptions universal
Re: (Score:2)
"Never to use the code on a phone conversation eliminates the phishing risk" is unfortunately without merit.
It has merit for me. It's a 6 digit code that's no big deal and frequently facilitated by a copy/paste. It's not asymmetric encryption, but it's easy to enable through arbitrary infrastructure.
They are with few exceptions universally supported. The technology has been in widespread use in corporate settings for well over a decade.
In this case, my experience is that it is *rarely* supported. I've *tried* to use it. I've seen the problems trying to get services to support it. Maybe in your personal context it's almost ubiquitous, but my context is that almost nothing supports it, therefore it's demonstrably not universally supported. I have a
Re: (Score:2)
It has merit for me. It's a 6 digit code that's no big deal and frequently facilitated by a copy/paste. It's not asymmetric encryption, but it's easy to enable through arbitrary infrastructure.
TOTP does nothing to prevent phishing. The notion TOTP is able to prevent phishing is without merit.
In this case, my experience is that it is *rarely* supported. I've *tried* to use it. I've seen the problems trying to get services to support it.
Maybe in your personal context it's almost ubiquitous, but my context is that almost nothing supports it, therefore it's demonstrably not universally
Firefox supports client certificates.
Chrome supports client certificates.
Edge supports client certificates.
IE supports client certificates.
Safari supports client certificates.
Opera supports client certificates.
This technology has been widely supported for a very long time. One can't just wave their hand and pretend otherwise.
There's no protected namespace where javascript can't set the same headers, and even if there were, non-browser clients have free reign. So if done incorrectly , a client could connect unexpectedly bypassing proxy and say 'X-IDENTITY: ceo@mycompany.com' and if you aren't careful in your backend, it'll shrug and say 'ok then'.
The concept that if x is done incorrectly than y is insecure as consequence is univ
Re: (Score:2)
TOTP may not prevent phishing, but that is commonly otherwise handled (server certificate, for example).
Clients may commonly support some mechanism, but a lot of server software does not support it.
Reverse proxy relaying client tls info as headers I view as more fragile than other solutions because it's based on a mechanism that is forward-by-default (unrecognized headers are generally relayed by a proxy), and the endpoint frequently does nothing to have a hard assurance that the relayed header information
Re: (Score:2)
TOTP may not prevent phishing, but that is commonly otherwise handled (server certificate, for example).
Also does not prevent phishing.
Clients may commonly support some mechanism, but a lot of server software does not support it.
ALL major web servers support it.
Reverse proxy relaying client tls info as headers I view as more fragile than other solutions because it's based on a mechanism that is forward-by-default (unrecognized headers are generally relayed by a proxy), and the endpoint frequently does nothing to have a hard assurance that the relayed header information is authentic. So you don't have a design that fundamentally extend all the way from authorization engine to client, and so we have a fragile hop between the TLS endpoint and the authorization bit. This isn't speaking from some abstract theoretical, it's from auditing a number of deployments where these sorts of mistakes are made all the time. People aren't good at thinking about what if the client isn't the proxy, or that they need to prevent insecure paths, or that a proxy must always drop client headers that may overlap with the client certificate information.
Bypassing the proxy may be possible even if the traffic can't be intercepted, if the backend is unwittingly routable, but the nominal path taken is beyond the reach of spoofing in.
You are basically preaching to the choir. I generally dislike proxies and recommend people avoid using them.
If you accept that the channel is insecure than from a security perspective you've already failed because your application won't be secure either.
For proxy chains that terminate TLS you basically have two choices.
1. An internal proxy chain that is magically deemed trustworthy.
2. Use of mutual authentication (client certs) between trusted
Re: (Score:2)
TOTP doesn't require a data connection or a phone. If you're accessing Github without a computer, well, you must be a pretty special case then. I'm sure they'll miss you dearly.
Re: (Score:2)
I have my github OTP imported into my FreeOTP+ app as well as in KeePassXC on my laptop, with my password database on network replicated storage. No network connectivity required, works across many devices.
Re: baby, bathwater. goose, golden egg. (Score:1)
Why the hell would anyone not want to do 2FA?
This is the IT equivalent of refusing vaccines. It's just ignorant and dangerous
Re: (Score:2)
2. Security keys are expensive, and not one of them will work on every device I own
3. Apps are made by people who I don't trust
4. Generally take to long to come in
5. My phone is not a security device. It is a glorified iPod that auto downloads podcasts and allows me to look at porn when on the go.
MFA has never seemed to add more security. Just more inconvenience. I am pretty sure you could convince most to give up that code when asked. It seems to me that it is used to cover
Re: (Score:2)
pot. kettle. black.
2fa is insecure whether using text or totp. It is also a huge pita for the user.
https://www.transmitsecurity.c... [transmitsecurity.com]
client certs are more secure.
Programmer gets hit by a bus... (Score:3)
Why? Because companies must be prepared for the following scenarios:
2FA creates a single point of failure for resources - yes, that's why it's secure
Re: (Score:3)
FTA: "a surprisingly low figure given that the platform's user base should be aware of the risks of password-only protection."
The thing is, what are you protecting? In a meeting once, I pulled out a penny, placed it on the table and asked our security developer, "How much money and effort would you put into protecting this penny?" My point was clear: it's not just security, it's also what you're securing. The platform he wanted to secure didn't have anything of value on it, though it wasn't true for other parts of our infrastructure.
2FA is stupid (Score:2, Insightful)
2FA is stupid. My phone is usually in my coat pocket for when I'm out. But Hanley thinks I should need it on my desk at all times. Now my phone is at greater risk of being stolen, lost, or broken ... all of which will hose me and lock me out of Github for days until I can buy a new phone with a new number and re-set my ... oh, snap, without 2FA I can't reset my 2FA ...
Re: (Score:1)
I use signed commits and disallow unsigned ones as well as squashed merges. Should someone get hold of my private key, I've got far bigger problems than them being able to sign into GitHub as me via a compromised password.
Re: (Score:1)
this.
2fa is not gonna fly here. now if they made ssh usable through the web interface somehow, that would be ok with me.
Re: (Score:2)
You can back up your TOTP secrets. If you have another device like a tablet, you can install the auth app there and import your secrets. Or, without very much difficulty, you can write a Perl script to mimic the OTP app (but make sure the secrets are stored in an encrypted filesystem!) so you can auth right from your desktop.
Re: (Score:2)
Then get a YubiKey. Smaller, more secure, and much more convenient. Geez...
Erm... You did download and save the collection of one-time use recovery codes for just such an eventuality, didn't you?
Re: (Score:2)
I feel like Yubikey would be at least equally a problem. If he's concerned about access to his handheld making it more likely for him to leave it behind, then certainly he'd have that problem with a yubikey. If lost, his ability to locate his yubikey may be challenging. On security, if people are leaving their key handy because they have to authenticate to something or another ever so often, then it may be a risk that they leave it behind in an open work environment, perhaps even more than a phone (you may
Re: (Score:2)
KeepPassXC is desktop software that among other things supports TOTP. I usually have TOTP style secrets in my phone (FreeOTP+) and my desktops so it's at hand either way.
Why do we let them unload on us? (Score:2)
We have to make security the company's problem without making us jump through the hoops. There's a reason only 16.5% use this stuff, because it sucks, and is not really secure. It just opens up your phone to more risks. I guess another burner phone is in order.
Re: (Score:2)
I can't see how WebAuthn or TOTP opens your phone to more risks. I think you'll have to elaborate on 'not really secure', at least compared to a human selected password. The only 'insecure' thing I can think of is that a human can be tricked into divulging their current numbers if they don't understand the situation well, but passwords are in the same boat.
Re: (Score:2)
Those don't open phones to more risk, they are existing risks to your phone that may further be leveraged to overcome MFA.
MFA doesn't *cause* these problems, they are problems that equally impact password authentication. So MFA is a subset.
Now one could argue that those possibilities are reasons for people to prefer more specialized, locked down security modules (e.g. YubiKey) for the role of authenticators, but I don't see any of those as reasons to say 'a dumb password is more secure'.
ITT: Children who don't want to use MFA. (Score:1)
ITT: Children who don't want to use MFA.
Re: (Score:2)
Pretty much. I'm still shocked there are people who don't.
Re: (Score:2)
Nobody cares about the code I put up as no one else has ever grabbed it. It's all weird niche stuff and nobody cares.
Why should I be required to deal with the hassle of 2FA when I don't have a phone and I fully accept the minuscule risks of my code getting compromised?
seriously problematic for commercial security (Score:2, Interesting)
this is exactly the nightmare scenario that has kept people such as myself, as well as those working in commercial high-security environments, from using github. imagine that you are a company supplying Military, Defense, or Banking clients. you are required to provide full source code for Audit Purposes. github forces all of your employees to enter their personal details into github's system, which now exposes all of your employees to serious risk of being taken hostage, blackmailed into putting backdoors
Re: (Score:2)
Huh? What personal details are employees "forced" to enter? Github supports TOTP, which is completely anonymous.
Re: (Score:2)
I assume 99% of the people do not know what TOTP is.
Certainly I'm one of them.
And: I do not want 2FA ... if my ordinary authorization is not good enough: so be it.
Re: (Score:1)
Yeah, man! Ignorant and proud of it!
Re: (Score:2)
If this is what prevents people from putting high security code on third party sites on the internet... good I guess?
Re: (Score:2)
If this is what prevents people from putting high security code on third party sites on the internet... good I guess?
i gave the high-security example as an actual real-world example of a Company i know that genuinely does do work for Defense Contracts and Banking. they are a fully-committed company to "Full Transparency" and as such they genuinely need the benefits of Libre/Open Development, understanding as they do that obfuscation and fear of being "caught out" has been shown time and time again to be the complete opposite of safe development practices. they *need* eyes-on in order to avoid making mistakes for their cu
Re: (Score:2)
Uh, how is having two factor authentication "policing your online identity?" And how does it prevent someone uploading the code they just wrote for the military to Github?
Re: (Score:2)
Re: (Score:2)
2FA doesn't require any of that.
I have github 2FA enabled through TOTP, which is just a machine generated shared secret, with no demands on stricter identity.
It's already 2FA (Score:2)
The password from my mind, and a physical object, my computer.
Re: (Score:2)
When you change your daily computer use to another computer, how do you enroll that computer as a second factor?
Re: (Score:2)
Same way as my phone. An app runs on it. For the PC, it's a "web app", identified by a cookie.
Re: (Score:2)
Let me phrase it a different way: When you run the 2FA enabled web app for the first time on a particular computer, how do you authenticate to the web app in order to plant the cookie?
Are you telling me.... (Score:3, Insightful)
Re:Are you telling me.... (Score:5, Informative)
You might want to read a bit, maybe try some yoga or meditation for that blood pressure. But mostly read a bit.
The two factor authentication is for the web interface. You've never been able to log into that with an SSH key (that would be weird). And they use TOTP, which is an open standard, so you can use any number of apps, regular programs, write your own using libraries for most major languages, or roll your own using the published algorithm.
Re: (Score:2)
why would ssh login via web interface be weird? It's actually weird that it is NOT supported.
Re: (Score:2)
I like using SSH keys for weird stuff, but the fact that it's not done is what makes it weird. If you were going to use an SSH key for a web login you'd have to have some kind of challenge response system set up, your browser would have to know about your key, etc. Unless you just paste your private key into the password box, which is a really bad idea.
Re: (Score:1)
I know. I'm saying it seems kinda weird to me that after all this time browsers do not natively support ssh, or at least that someone would have made an extension or library to do it.
Re: (Score:2)
Because SSH is a command line protocoll going via port 22.
And a web interface is a graphical interface - granted it goes via text as HTTP - which goes over port 80/443.
Assuming SSH keys might/could work for HTTPS is kind of absurd.
Re: (Score:1)
not really. ssh can be routed over any port and an ssh key is just another kind of client cert. the surprising thing is that browsers haven't integrated it yet.
Re: (Score:2)
That is basically my point.
XyZ over SSH (Score:2)
Because SSH is a command line protocoll going via port 22.
And a web interface is a graphical interface - granted it goes via text as HTTP - which goes over port 80/443.
Ever heard about Socks proxy? Port forwarding? X11 forwarding?
Or using SSH to wrap encryption over some software's iinput/output stream (git, rsynd, 'ssh -W' jumpoints, etc. )?
bash is far from the only thing that you can carry over an SSH link.
(case in point, I litterally use ssh port forwarding to securly access a Jupyter Notebook server at work when I am away)
Assuming SSH keys might/could work for HTTPS is kind of absurd.
HTTPS litteraly supports using public key for logging in. (Okay, it's not litteraly SSH Keys, it's your usual SSL certificates instead, but the mech
Re: (Score:2)
Exactly. SSL certificates are not the same as SSH keys.
And you can not SSH tunnel to a remote server you have no control about, unless the owner assigns you keys.
Public key logging (Score:2)
You've never been able to log into that with an SSH key (that would be weird).
Logging in with a public key is a thing, and it's a standard supported by browsers.
But I've only seen used in some corporate settings (using hardware keys in hospitals and at the army) and with key issuers (you can sign back with the key they created at CACert.org, SwissSign, etc.)
It's not very common on popular websites like Github.
Re: (Score:1)
maybe try some yoga or meditation for that blood pressure
What did you say to me, you little... !!! Kidding. Yeah stress has been exceptionally bad.
Re: (Score:2)
And they use TOTP, which is an open standard, so you can use any number of apps, regular programs, write your own using libraries for most major languages, or roll your own using the published algorithm.
Sounds like a lot of trouble if the web interface is something you only use occasionally. Reminds me of how Java wants me to sign my own code just so I can run it on my own computer. Can't take chances when it comes to security, you know!
But, hey... virtues gotta signal. My take on 2FA is that anything forced upon you is not in your best interest, no matter what the marketeers (or even your fellow nerds) tell you. Telling everyone to do something stupid because it's easy and "no big deal" is just balone
Re: (Score:2)
What `ceoyoyo` said: Go do some reading. Github does TOTP correctly, without requiring a phone number or sending SMS messages (although that's an option).
There are several TOTP apps for Android; an Internet connection is not required for them to work. Google Authenticator [google.com] is one, but if you don't t trust Google, then check out andOTP [github.com], which is available via F-Droid. The only system permission andOTP wants is for the camera, and that's only so it can scan QR codes off the screen when you're setting up 2
Re: (Score:2)
Re: (Score:2)
SSH key is accepted for git, but if you want to use the website features (issue management, documentation, release management etc.) then you need 2FA. You can use your choice of OTP app or a security key.
Microsoft is doing this globally, corporations too (Score:3)
Microsoft is trying to replace password-based logon completely. They are rolling out "Windows Hello" to corporations, which replaces a password with a pseudo-biometric (thumbprint or face image, depending on the hardware) + a device-specific password (they call it a PIN for some reason). The idea is that you can't just login from any device, you have to first enroll the device, setup the pseudo-biometric, then you can login.
I suspect github is them just moving in this same direction.
Re: (Score:2)
The idea is that you can't just login from any device, you have to first enroll the device, setup the pseudo-biometric, then you can login.
Or more to the point: You cannot login until they allow you to.
In a world where you have pretty much everything online, or headed that way, I can only imagine the ghouls who would do anything to have control over the "disable account" button.
Re: (Score:2)
Or more to the point: You cannot login until they allow you to.
You just described logins. You're incredibly insightful.
Re:Microsoft is doing this globally, corporations (Score:4, Insightful)
Microsoft is trying to replace password-based logon completely. They are rolling out "Windows Hello" to corporations, which replaces a password with a pseudo-biometric (thumbprint or face image, depending on the hardware) + a device-specific password (they call it a PIN for some reason).
That's one of the reasons I stopped using Windows. That biometric shit is a giant step backwards.
There's nothing inherently wrong with a password. As long as the password is sufficiently long, and re-tries are timed out (a few seconds is plenty) to avoid brute-force attacks.
It's not broken, so I don't trust any company that says they have "fixed" it.
Re: (Score:2)
ESpicially Microsoft. Which has a thirty year record of poor security on their devices.
Re: (Score:2)
Passwords are broken. If you are sufficiently long, people forget them or they re-use them. Human beings are just not good at storing passwords.
Okay, you use a password manager instead. This is going to slow down your Windows log-on. You also have the hassle of where to keep it - are you going to provide your employees with phones, or trust them to keep the password manager on their personal device (if they even agree to that)?
There are plenty of common situations where biometrics are much better than passw
Re: (Score:2)
Passwords are broken. If you are sufficiently long, people forget them or they re-use them. Human beings are just not good at storing passwords.
What is broken is the underlying technology not the concept of passwords themselves.
Passwords don't actually have to be long and complex to be effective if the underlying technology is implemented properly.
People could use words or pictures instead of random characters which offer more entropy for the same effort to remember.
There are two big problems in current systems.
1. Use of insecure authentication most commonly passwords transmitted in the clear over encrypted TLS channels. This unnecessarily exposes
Re: (Score:2)
Words and pictures just mean it's easier to do a dictionary attack.
Re: (Score:2)
Words and pictures just mean it's easier to do a dictionary attack.
How does increasing entropy make a brute force attack easier?
Re: (Score:2)
Passwords are broken. If you are sufficiently long, people forget them or they re-use them. Human beings are just not good at storing passwords.
https://xkcd.com/936/ [xkcd.com]
Last time I searched this thread, I didn't see this XKCD comic linked anywhere. What has Slashdot become?
Re: (Score:2)
That comic is bad advice. It's relatively easy to break with a dictionary attack.
Re: (Score:2)
I've ever actually seen a real dictionary attack. Then again, that may just be because I live in a shithole country where the broadband is terrible, and therefore our shitty infrastructure acts like a timeout to make such attacks impracticable.
But yeah, with a sensible timeout (a couple of seconds after each attempt is plenty) then a dictionary attack doesn't work. Especially for a password of the length suggested in that XKCD comic.
I would much rather see a timeout after a wrong password attempt, than be r
Oathtool (Score:2)
On Windows, you can use WinAuth [github.com].
On Linux, you can use Oathtool [nongnu.org].
Re: (Score:2)
Or use KeePassXC for both, along with password storage.
We are doomed. (Score:3)
Re: (Score:2)
I think people (in the know) are concerned mostly about identity provider silos, and not the tinfoil FUD fluff you're blabbing.
It will be interesting to see how OTP is no longer "the most obvious", whereas Microsof/Google provisioned TPM/TEE strongbox siloing your identity on your own damn device is somehow the most fucking obvious thing ever.
Another shitty requirement... (Score:1)
...from another shitty company. Fuck'em. They ain't the only game in town.