This is a Medium blog on an nytimes.com subdomain, so perhaps you've hit an account or browser specific limit. I'm not getting a paywall in or out of private browsing mode, you may be able to get around it easily.
While I like my Yubikeys, they definitely aren't more convenient or intuitive for people who aren't accustomed to using multifactor authentication already. The webauthn spec [0] includes support for "biometric authenticators" and "platform authenticators" (e.g. the fingerprint readers with secure enclaves increasingly present on phones and laptops), and I think that has a real chance at improving authentication security across the board. Once Apple, Google, and the like start pushing "touch to login" via webauthn, people will come to expect that sort of convenience. And if all of your devices include these authenticators, adding a new device should be as simple as authenticating on one that hasn't been lost or stolen.
It's only a stupid premise if you take the feature for face value and assume that the people behind it expected it to magically solve all of the tracking problems on the web. Alternatively, consider that it's a great opportunity for all those companies that "value your privacy" to put up or shut up. Then tools like Privacy Badger [0] get to call out advertising companies that assert that they only track consumers because that's what consumers want while explicitly ignoring the industry standard opt out mechanism.
There's a similar effort in the Python / Django world called Jazzband (https://jazzband.co/). This model will probably become more and more necessary as maintainers need to move on from projects for whatever reason. Having a safe place to transfer a project to with a formal process (announcement of the change, code review before acceptance, etc.) would certainly help combat this issue.
Yes, I was inspired by Jazzband, but Jazzband has two things that led me to develop Code Shelter: It's pretty specific to Django, whereas I wanted something general, and people have to move their projects to the Jazzband org, which many people don't like doing (because they understandably want to keep their attribution).
With Code Shelter you don't have to move the project anywhere, you just give repo admin access to the app and the app can add/remove maintainers as required.
There's obviously a corrective component as well, where maintainers who don't do a good job are removed, but this hasn't happened yet so it's not clear how it will be handled.
I think plenty of people in the Python community will earnestly say that while acknowledging that there isn't universal agreement on what that one good way is. It's an ideal to strive for, not a statement of fact.
The PyPA team has done a lot over the past five years. The changelog for pip (https://pip.pypa.io/en/stable/news/) contains quite a bit, PyPI was migrated to Warehouse, and there have been several PEPs focused on improving the packaging situation. A lot of these ideas come from various people in the community and get formalized as official recommendations or tools, but these things take time, especially accounting for backward compatibility in an ecosystem as large and mature as Python's.
The short answer to "why isn't this solved?" is "it's hard, and there's a lot to do". Development practices change over time, and the tooling continues to evolve with them. It's easy to see a broad survey like this and think that there's too much going on, but taken at a high level, the space is definitely trending in the right direction.
(Note: I'm not part of the PyPA, but I'm interested in this area and try to follow along from the outside.)
Understood, I guess I'm wondering why it hasn't been possible to cull more of the less-successful attempts, or at least make it obvious to newer users what is legacy. As an outsider/newer person to Python, the number of package mgmt options to consider is vast and confusing, it would be helpful if there was one (or a few) more "blessed" solutions :)
> the number of package mgmt options to consider is vast and confusing
Part of the issue is due to the success of Python in very different niches. The likes of Rails or Node can concentrate on specific ecosystems, which account for the bulk of their users and have a limited set of scenarios they have to support; whereas Python users come from sysadmin to data-crunching to web to desktop development to games to to to...
So each packaging tool comes with certain ideas, usually a result of the author's experience; maybe they work very well in this or that scenario, but then they break badly on others and sizeable chunks of the community revolt. So a new tool comes around and the cycle starts again, but now people also want compatibility with the old tool.
I suspect part of the solution will require splits between niches. It already happened with Anaconda, which has basically become the standard in a particular group of users (academia / datascience). Since that came around, lamentations around building C libraries have substantially reduced (to be fair, the arrival of precompiled wheels on PyPI also helped). Some similarly-specialized tool might eventually emerge as standard for other niches.
Python developers are cats and they are pretty hard to herd at the best of times, which is unsurprising -- who would stick around a language that is almost 30 years old and was never promoted by any major vendor? Only hard-headed fools like myself.
There are some "blessed" recommendations at https://packaging.python.org/guides/tool-recommendations/ (the Python Packaging Authority is about as official as you're going to get), but this boils down to it being a large open source community. No one's going to cull other people's efforts, but tools do merge on occasion (e.g. the functionality of https://github.com/erikrose/peep has been merged into pip, so peep is deprecated now).
I quite liked Vienna (http://github.com/ViennaRSS/vienna-rss) while I had a Mac. It has options to run both as a standalone application and synced with various online services.
Can anyone comment on their "zero touch is safe" claim (https://krypt.co/faq/)? As far as I understand, tokens like YubiKeys require a touch as an explicit action by the user to prevent authentication without their knowledge. Doesn't a zero touch approach remove a security feature?
You pair your phone and browser and then they can talk. Any time you want to log in through that browser it can talk to your phone and auth you automatically. For someone to exploit this, they'd need access to the computer with your browser.
So if your laptop gets stolen, yes this is a bad idea, but I think most people think that they can just revoke the browser's keys if if the laptop gets stolen and they are way more likely to have their phone stolen anyway.
I was more thinking of malware / some otherwise rogue process. This seems like something that's worth having in the world of fake support remote desktop scams.
1. Wait for user to sign in.
2. Intercept their sign in.
3. User: "Oh, it didn't work. I'll just try again."
4. User tries again and it works. Attacker is also logged in now.
Alternatively, at that point you could just inject JS into whatever website needed 2FA and do everything without the user noticing anything.
It wouldn't matter if they had their laptop stolen unless they also had their phone stolen. The keys are on the phone. Any new auth attempt would require the phone in proximity of the laptop. It connects via Bluetooth, not over the internet.
I haven't researched their claim, but my guess is that with something like yubikey you wouldn't know an authentication has happened. with Krypton, there would be a notification pending on your phone. Possibly you would only be able to authenticate if your phone is unlocked as well.
When Krypton asks you to authorize an access, you can tell it to authorize that single access, authorize the host for three hours, or authorize everything for three hours.
I typically authorize the host for three hours, meaning for the next three hours I don't have to Touch ID in again.
I disagree that it's clear. Words have meanings, and
> By "unlimited", we really meant "limited".
shouldn't be a valid defense for misleading consumers. The plan would be more accurately described as "15GB 4G LTE Data". If the limits were stated more prominently, the fire departments could have avoided confusion and worked with Verizon or a competitor to get on a plan that wouldn't stop working at the worst possible times. Verizon could have also avoided some bad press by just waiving the fees and sorting things out later instead of demanding extra money during an emergency.
