Yet another new service that 1Password is doling out only to those who buy into their new subscription model. Users who, like me, paid three times to buy the app for all their devices are left out in the cold.
I still love 1Password, but this treatment makes me unhappy.
Presumably it costs them money to develop these new features. Why do you feel like you should have access to new features if you are not a subscriber?
Usually when I buy a software license I expect to receive bug fix updates for that version of the software, but I don't expect to receive feature updates (without paying an additional upgrade fee). Someone that paid for Photoshop 5 did not get Photoshop 6 for free.
> Presumably it costs them money to develop these new features. Why do you feel like you should have access to new features if you are not a subscriber?
Nobody said anything about not being willing to pay money for (new) software/features.
The problem is the subscription model. On of the problems with subscriptions is you loose track of what (new features) you are paying for.
Especially when you don't have a lot of money, this is problematic.
When making a 1 time purchase, it's very clear what you are paying for.
(and cloud services are free already with iCloud sync/Google drive/etc. so the 1password cloud is superfluous, feels like just another excuse to sell a subscription model.)
I mean, are you aware that you are paying $2,99 * 12 * 3 = $107,64 for 3 years of 1Password usage? And that's just 1 of the many app subscriptions...
Subscription model is the only one that makes any sense. These days you can't expect to run a program for many years, because the environment changes too quickly. Programs need to be updated for newer OSs and the world that changes around them. This costs money.
I am happy to exchange money for new versions of software that offer new features, or for compatibility with new versions of operating systems. I expect to pay money for software, have it functioning and supported for an agreed period (say, a couple of years), and then to pay again if I want to continue using it with fancy new features.
That doesn't seem unreasonable or difficult to offer?
I've seen this model used at collectorz.com - you buy the software, and it comes with one year of updates. When that year expires, you are basically frozen at the last version of the software, or you can choose to buy an additional year of support for about half the cost of the initial purchase. Seems to be a reasonable compromise to me.
At what point are software developers obligated to provide purchase models to suit you? Is not like there's an inherent right to have whatever software you like in whatever form or payment model you like, any more than the OP complaining that somehow having bought multiple versions of software isn't getting a new feature back ported.
I should be clear that nobody’s obligated to do so! Sell your software using whatever model you want. But I think it’s fair to complain when companies don’t offer basic models like “sell me new versions of your product in exchange for money”.
I agree. I'm thinking about the commercial software I've bought - most of it doesn't include perpetual upgrades (I'm a 1Password license holder who bought into the subscription when it became available - it's easily worth the $7 I pay for my family)
Agreed. This idea is essentially that you entitle yourself to all of someone's future time because you paid them for time they already invested.
They already give you future time in the form of bug fixes. To ask for more is blind entitlement and quite silly, yet absolutely rampant.
It's kind of like how we say everyone should work in the food industry for a while because it sobers you up to reality. Maybe the same should be said for trying to sell software or run a website that has actual users.
Those are two additional ways to see how poorly some people will regard you no matter what you do, just like working in the food industry or retail.
People who pay for the products of early-stage startups (or, say, back Kickstarters) have an emotional intuition that they've invested in the company, despite there being no legal truth to that fact.
As a growing company, you have to keep that in mind when modifying your business model: you can't betray the (entirely incorrect!) emotional intuitions of your customers, or they'll boycott you.
Actually you can. I've heard it called "firing your least profitable customers."
I haven't heard too many postmortems of people that've gone "we should've given in to the entitlement of a portion of our users." But I do hear the opposite.
That is true, but the price structures are different. Stock prices, and other equities, are already priced with everyone knowing that you have permanent ownership. Software isn't priced that way. If it were then I would expect prices to be much higher.
This is a proof of concept that is only available on their subscription service simply because the website version of 1Password is tied to the subscription service. If you read the article they said they'd be adding it to Watchtower, which is the feature built into the native client where it tells you about compromised sites. So once they add it to Watchtower, you'll be able to use it without the subscription service.
I switched from a Mac (died) to a Windows machine, and have lost some 1Password functionality with the change. I too dislike the subscription model.
Thinking of perhaps signing up to their online service with a one-time credit card number with a one month expiry date. This will ensure I do not get charged monthly for a service I do not want. I want to check password vulnerability with this new online-only security feature once in a while and create a back up PDF report of all 1PW entries for storage in my fireproof safe.
I love 1Password; the application got me through a natural disaster and displacement with a minimum amount of technical issue. Unfortunately AgileBits are making decisions that reduce the functionality of the software.
Yeah, I'm pretty annoyed with the subscription switch as well considering the investment I'd already made in their software many times over as a long time user. Sigh.
I don't see how you can be against subscription pricing for living software. You're paying the publisher/developers to continue developing and supporting the software and run associated services. It's the only sustainable model for long lived software and 1Password is good enough to be worth it.
In this case, the subscription service doesn't allow for local vaults. You need to be using the 1Password hosted cloud service to store your passwords. For most of us that is a nonstarter.
This isn't true. Open up Preferences, go to the Advanced tab, and there's a checkbox "Allow creation of vaults outside of 1Password accounts". Check this and you can create local vaults again.
I believe it's disabled by default for 2 reasons:
1. Simplicity. Most people who use the subscription service don't want local vaults, because they won't be synced or available on the web (or subject to administrative controls). By disabling local vaults, you can't accidentally create one.
2. Once you re-enable local vaults, you have a local Primary vault and unlocking that is how you unlock 1Password on this computer. This is a potential point of confusion, because you'll be using a different password now than your 1Password Account password, which comes back to the simplicity angle.
If you already paid a substantially higher price when they were non-subscription based, it can rankle. Especially if the amount paid would have covered well past this point if subscription pricing was available at the time.
I don't think people are complaining that it's a subscription much as they are complaining that the switch seems to leave them with only semi-supported software relatively soon after a full price purchase (even if that may or may not be an accurate assessment of reality).
They are complaining about both, which means they might have a good argument but it's infected with their bad argument.
Can't have your cake and eat it, too. But I suspect they also just don't want to pay a subscription. Well, who does? I also don't like having to pay for coffee.
There is nothing wrong with full price software. It fully works, it just needs to be clearly outlines how long your support lifecycle is, which many companies don't think about. Pay full price, get X years of bugfixes (and access to new versions, depending) from date of purchase.
There's three types of model really, and the problem is when companies have multiple models in place and don't treat them equivalently.
Pay in advance - This is like buying a car. You get a warranty for certain covered problems. Costs a lot.
Pay subscription for local software. - This is like leasing a car. You pay a lesser amount each month, but have full usage of the vehicle. You lose access at the end of the lease.
Pay subscription for cloud based software - This is like using ride-sharing (or maybe a community shared vehicle system) for everything. You have access to the software on demand when you need it, and lose access when no longer a member / you stop using it.
All these models work. The problem with some full price software is they were selling it like it had a warranty and not defining the warranty. Expectations are all over the place, and when they don't match reality, people get upset.
Additionally, in this case people are upset about how there's two models in place and they don't appear to be handled the same, as they had some expectation of a type of warranty with full price software, and all of a sudden it feels like the company has changed how they are handling warranty requests for already sold full price software.
As a company, communicate clearly and follow through with that you've stated, and these problems go away.
I don't want any associated services - Dropbox will host and sync the password wallet files for free. Their other service is downloading icons for websites, but I don't want to send them a list of all my websites.
Yes, there is the occasional need to update Dropbox API code, or Chrome/Android API changes, but their asking price is very steep.
I already paid over $60 for the Android and OS X versions.
For 1PW it might be ideal to push updates and not charge for them. As a security/tool provider out of date software could be compromised or have issues which might damage their public image.
You say three times as if that is more valuable than paying every month. I paid $35 in 2014 for both the Mac and windows version. I might have upgraded the Mac version once, but anyway you calculate it, I paid way less than subscription pricing.
Every time 1Password is mentioned here, the top comments complain about their new subscription model. And yet, they've never made any noise suggesting it isn't working out well for them as a company.
I'm beginning to think that it's just the HN echo chamber, and that the majority of users (the sort of people who have never filed bug reports against a compiler, let's say) are fine with reasonably priced subscriptions. As a techie, this rubs me strangely, but as a budding indie developer, it's rather reassuring.
There's several things that drive me crazy about 1Password, but subscriptions aren't near the top of that list.
Slightly OT but anyone has a REALLY easy password manager solution?
I tried migrating my entire family to a 1Password family account. Honestly for people with limited tech-knowledge even 1PW is still too complicated.
- In 25% of the cases it does not save e.g. the username correct. Explaining my parents how to open the app, edit the login, etc. is just not gonna work.
- they don't prefill logins (like e.g. Dashlane) so you either have to press the icon or do the keyboard shortcut. Again not suitable for someone who is not very technical.
- On some sites (even big ones) the user/password inserting simply does not work. Explaining them how to open the app, copy user/pass, switch to browser... not gonna work.
- generating random passwords and filling them on registration page does not work 100% either
- using it on mobile is just horrible.
Only thing I could come up with would be (on a Mac) the built in password „manager“. Any ideas? Hate people using their birthday as pw just because there is no easy solution to this problem.
My MIL literally has a notebook in her house where she writes down her passwords. I scoffed when I found out about this, but then considered, well, it's a lot more secure than what she was doing before she had it, and the chances of someone breaking into her physical house for it are pretty slim.
Maybe suggest that to them?
I mean, I dunno. Knowing how to press an icon or copy-paste content from one app to another is sort of computer table stakes in 2018. These are problems on the user end, not the product end. It would be terribly insecure if their passwords were just automatically input every time someone on their computer opened a login screen.
> ...the chances of someone breaking into her physical house for it are pretty slim
I find this to be quite an under-represented opinion whenever I encounter password security discussions. How many people's threat models need consider physical security of their house? Surely most people's number one - if not only - threat is using a compromised service, so a password manager is just another vector; albeit one whose raison d'etre is security.
I fully agree with you and it's nice to see that someone else is thinking pragmatically and not ending up arguing over three letter agencies.
If your machine with the password manager gets pwned then it's probably game over, and you can do that remotely for a networked device. So at the very least it's reasonable to compare the physical security of a paper notebook and a computer.
Yes you might have encrypted the device but as everyone is so fond of saying 'once you have physical access it's game over anyway', so by that logic the notebook and computer are as secure as one another as they both rely on physical security. Maybe the computer is even less secure as you can attack it over the network!
It's important to plan for disaster recovery though. That's probably a more reasonable fear - something like fire or accidentally spilling coffee over the book would be pretty bad. Maybe a backup copy in a waterproof fire safe would be a 'good enough' solution for priority accounts like email from where you can probably reset/recover all other accounts.
My approach is that anyone breaking into my home could do far more damage, and I'd have far more to worry about, than taking my passwords -- ultimately, nothing I have electronically is valuable/secret enough that someone is going to specifically target me and break into my house to try and gain access. Having a paper copy of my master password isn't much of a liability in that threat model (and probably makes me more secure day-to-day - I can use a longer, more complex master password without the fear that I will forget it and lose access to everything).
Also, petty thieves just don't care about your book of passwords. Just like they don't care about seeing if your hard drive is unencrypted when they steal your laptop - they just pawn it off.
Of course, the ideal for security is that the best options are so convenient that you might as well do them. But there sure is a lot of circlejerking that happens when someone is exposed as "doing it wrong."
I tried to convince my father to use a password manager and tried to explain that using the same 8 letter password for 75% of services is incredibly risky, but i got so much resistance from him .. in the end he wanted me to send him an article on why a password manager would be good. When I looked for something I could send him and thought about what I need to do to help him transition to using a password manager I realized that even though there are great services out there are I don’t want to be responsible for messing with his current way of doing stuff. So I let it go.
I use keepassXC (actually MacPass, which is brilliant and has an HTTPConnecter plugin that can talk to the Firefox addon keepasshttp) and it works great. Maybe not as fancy as 1P etc but free and open source. On iOS I use MiniKeePass which also works well.
This is the setup that I was going to suggest to him. Personally I find it not that complicated, just needs some time to get used to the routines.
Just make sure that the MacPass implementation of that HTTPconnector isn't listening on 0.0.0.0 by default.
Some implementations do and it has been patched in the main repo but didn't make it out to all users. Communication from KeePass/MacPass to the browser is just over http as the name suggests so passwords are sent in plain text and can be sniffed over the network.
If it's confined to localhost then you're fine as it's as secure as not having a compromised device in the first place.
> In 25% of the cases it does not save e.g. the username correct. Explaining my parents how to open the app, edit the login, etc. is just not gonna work.
Can you explain this issue a bit more?
I use 1password, and I would be very angry if it randomly did not record my input data correctly. Yet, it's been flawless. Whether it's a username, a custom data field, an email, a site, a custom password, etc - it has never not recorded a piece of data I gave it. I'm on OSX, Windows and iPhone.
Is there an issue here I should be aware of? Because not recording data is a big, big deal..
This usually happens to me when I do a reset password flow for a login that was previously not in 1Password. 1Password then saves the password, but not the login. It also happens sometimes when the password entry is on a different page from the login entry field. A third scenario that sometimes occurs is when a website mangled what was put into the login form before field submit (this usually only happens with ISP provided routers, but have seen other cases).
I just discovered today, looking through 1Password's "weak passwords" section, that 7 years ago I recorded a password for one "Optumhealthbank", and the recorded password was
****
My best guess is they used JavaScript to replace the contents of the text field before submission. Thankfully I've apparently never needed to use this password.
That said, out of 1000+ saved passwords, this is the only case like that I've seen.
Yeah, I think I could count the number of times that one has happened on one hand in the past decade, but it definitely has happened enough I remember it.
When you fill in a username/password combo and it pops up offering to save it as a login for you, it just doesn't know that there's a username field.
When you revisit that entry in the future. Like possibly the far future when your one-year-long session finally expires, you'll find out you only have a password.
Pretty bad UX. The popup that has [Cancel] [Save] should just show you the username and blotted out password for you to confirm.
I have a few entries where I was so paranoid that I said fuck it and copied my password right into the name of the website entry. So I'm wondering if there's a case where it only saves the username and not the password because it doesn't detect it? I just haven't registered for a website in a long time so I only remember the one case.
If you haven't encountered it, you're just lucky or, more likely, haven't yet noticed. ;)
> If you haven't encountered it, you're just lucky or, more likely, haven't yet noticed. ;)
3rd option, I don't use that feature :)
I create all my passwords before registration when I need them. So that's the weak point it seems. Hell, I don't even have the browser plugin installed.
I think 1Password's issues are a UI issue. I've been using it for years and I still sometimes can't find the "Edit" button when the app is full-screened because it's so far away at the bottom.
Also, the 25% failure you speak of is why I don't trust it at all. All it takes is one time where it doesn't save your username and it becomes useless.
So I just open it up and create entries manually. Which is fine for me but exactly something I wouldn't expect everyone to do since the app trains you to depend on its autosave.
I think a few UI changes would go a long way. I have a mental list and wish it would be worthwhile to build my own, as every developer likes to think. But in reality it just feels like a list of minor features/tweaks they can add eventually.
The most layman friendly thing I've come up with for parents/wife/kids/etc... is Safari on a Mac + iPhone using Apple's built in keychain manager. That's an insanely expensive solution compared to password management software though.
Every password manager has broken/buggy autofill on at least some sites. It's a really hard thing to get right, and the developers are always one step behind the changes that are made to the sites.
I’m not sure about family friendliness but I’ve basically moved to letting 1password and the iOS password manager coexist. iOS manager is basically fulfilling the role of cache + autofill from keyboard.
Lots of people may have recently switched to a password manager, and now use it to store old passwords that they haven't regenerated. It's very likely a common use case.
I've imported my passwords from Firefox's password manager to a dedicated one a few years back, and I've been generating new passwords ever since.
There's still dozens of occurrences of the one-password-for-all-services I've used previously, because nobody will go through the hassle of changing passwords in hundreds of online services. I do change it whenever the autofill appears too short to be randomly generated, but I still didn't get rid of all of them.
With that said, I'm not using 1Password and I've already checked my old password in Troy's service to make sure it wasn't in a breach.
If we'd use something like certificate auth it'd be less of an issue, but currently password managers are a horrible trend because they encourage using your password for a service for kany years. Ideally you'd rotate them every 60 days. Automating that is hell.
It'd be much nicer if we could just use OIDC with user-configurable endpoint.
Password rotation has been shown time and again to be worse than just using a unique strong password.
With rotation, there is a tendency to just use the same password but increment a digit at the end, or to write them down because people forget them. A password manager helps with this, but if you're using a password manager, then you can use a different password everywhere.
Password rotation was recommended in the days when people used the same password everywhere and had to memorize them because password managers weren't a thing.
Password rotation gains you nothing if you're already using strong, unique passwords. The best it will gain you is preventing your account from being accessed if they have already breached the password file, cracked it, and come back after the rotation period. But at that point they've already had access to the system and your password is meaningless anyway, so you didn't actually gain anything.
> "...if they have already breached the password file, cracked it, and come back after the rotation period..."
Suppose it will take 100 years to crack your strong unique password once the file is breached. If the rotation period is 90 days, rotation gains you something. Suppose they got the password file from a database backup. Your password isn't meaningless yet. You'll be fine as long as you rotate it within the next 100 years.
> Suppose it will take 100 years to crack your strong unique password once the file is breached. If the rotation period is 90 days, rotation gains you something.
A strong password takes billions of years to crack with current computing power, assuming an entire datacenter is coordinating offline cracking on your password in particular.
If the hackers have compromised the service to the point they are able to manipulate the service unnoticed, isn't the horse already a little out of the barn?
Passwords are a form of access control. I repeat: a strong password cannot be brute forced for billions of years. Even with technological advancements, most strong passwords are well over what’s required to literally be safe for a lifetime.
Certificates are not a form of access control, like I explained in my other response to you. They are a form of cryptographic authentication. Digital signatures cannot be revoked offline, which is a problem because they’re used by other parties for validating trust. Therefore, certificates have a built-in dead man’s switch that requires renewal.
Passwords are not used for validating trust. They’re not comparable to certificates. Stop using certificates as an example of why passwords need to be rotated, because certificates don’t even use “rotation” in that sense of the word.
> Passwords are a form of access control. I repeat: a strong password cannot be brute forced for billions of years. Even with technological advancements, most strong passwords are well over what’s required to literally be safe for a lifetime.
The topic was never about brute forcing, that’s irrelevant.
It’s always about exfiltrated passwords, certificates or session tokens.
You usually have additional authentication requirements so that changing the password requires more than just the password, but an attacker that exfiltrates the password can still read everything.
For example, an attacker that obtains my onlinebanking password will be able to read all transactions, but not make changes. In this way, the password acts identical to a session token – an attacker exfiltrating a session token will get the same access.
The goal is to reduce this ability – changing the password as often as the offline session token ensures that if an attacker had such read access, as is possible with many services, this access will not continue forever.
With your suggestion, of using an identical password for decades, a potential attacker has for decades read access to the bank account. This is undesirable.
Yes, preventing exfiltration would be better, but exfiltrating session tokens and passwords is identical in terms of attack surface, and as result, they should be protected identically.
I'm talking about automated password rotation. A new 128 byte random base64 password every month.
Rotating credentials is important, even if you automate them. For the same reason that Let's Encrypt only provides certificates with 90 days validity, and that OAuth2 Offline tokens are usually limited to 90 or 180 days.
Ideally we'd use OAuth2 for everything, as that'd allow proper usage off offline tokens that allow the client to generate short lived session tokens, but we don't, instead we're using passwords everywhere, and we'd ideally want to have the same validity there.
The optimum would even be using challenge response authentications, or client side certificates.
This isn't a comparison of manual password management to password managers, but a criticism of password managers when compared to 30-day rotation cycle of client-side certificates.
Rotating passwords is only important if the site has been compromised (or you've been compromised, such as being phished). For the former, 1Password already has the Watchtower functionality where it tells you if a site is known to have been compromised since your password was generated, and for the latter, well, if you're being phished then you'll probably figure it out pretty quickly when the attacker steals your account.
In any case, if you really want to rotate passwords, 1Password has a "Security Audit" section with sections for "3+ years old", "1-3 years old", and "6-12 months old" passwords (and duplicate passwords, and weak passwords, and watchtower alerts), so you can rotate if you want to.
Rotating credentials is also important as an additional layer of security to prevent misuse.
Sadly, currently this all is highly theoretical. The first thing we should focus on is getting 2FA (TOTP/HOTP or U2F) authenticated login on every service that doesn’t use OIDC. Even this very site, HN, has no such functionality (@dang, @pg: Why?)
This is a much more important first step, and once that’s fixed, we can look at improving credential rotation, and providing global SSO with browser credentials.
I'd wager HN doesn't have 2FA because there's not much damage you could do if you compromised someone's HN account. At best you can pretend to be someone else for a bit, but in most cases that's harmless. There's only a handful of accounts I can think of where it would be problematic if someone started impersonating them.
I work in online gambling and 2FA is a feature everyone says they want but doesn't use because it's annoying. Just query the amount of users actually using 2FA on your site if you've set it up. Now compare it to the number of people who said that they can't take your site seriously until you have it.
I'm not saying 2FA is bad, but these people like the person above lives in a hilarious bubble if they think a website like HN is missing out by not having it.
It comes off as concern-masturbation, if I may be so vulgar.
By the way, the best thing we did for security across our gambling network is to generate passwords for users. Nobody uses 2FA, and the people that use it aren't the ones that need help. But everyone reuses passwords.
I think MFA is important and have it enabled for every service that offers it, but we have MFA set up for our CLI access to AWS and I used to let out a volume of curses frequently when my token expired.
I eventually ended up adding a bash alias “damn”[0] that pipes my current MFA token into the AWS CLI so whenever it expires I can just type “damn” and be logged back in.
I like the magic link approach Slack and Medium use - although I have frequently cursed the inconvenience of having to log into gmail.
As someone who uses a Yubikey for physical 2FA, I happily use it for things like my email and Github but then I just click trust the device for X days because, yeah, it can be a pain every time.
I'm moving to KeepassXC currently and if you use a Yubikey challenge, you (by default) have to press it anytime you save or update a record which is a big pain. I think you can change it but I worry it might crash (I'm running unstable for the browser extension) or I might forget to save
Personally, I use Yubikey or TOTP (with RedHat’s FreeOTP) for everything.
But that can only work if most services you’re using are using SSO, and you rarely need to reauth. I need to reauth every time I log in, every time I want to authorize a new service, or modify server, DNS or storage settings.
This only works well because I’m self-hosting 90% of the services I use, and they use a Keycloak as identity provider, and then don’t have to handle identity themselves.
This is why I’d prefer to see more identity federation – ideally the tokens the services see are short-lived, but the user doesn’t have to re-login every time either.
> I'm talking about automated password rotation. A new 128-bit* random base64 password every month.
Rotating credentials is important, even if you automate them.*
To be clear, you’re aware how absurdly long it would take to complete offline cracking for a single, randomly generated, 128-bit password, right? From a purely statistical perspective, what you’re advocating doesn’t actually make sense. It can only impose usability friction.
Unless you know a site’s password database has been compromised, you shouldn’t change the password. If it has been compromised, your password is so strong that you could honestly let just about every computer in the world try to crack it and still be reasonably confident in its continued security.
Password managers empower you to do that, but with a different password for every single service you use. You set it and forget it because you don’t have to do anything else. Simpler is better for users.
> For the same reason that Let's Encrypt only provides certificates with 90 days validity
I’m sorry, but no. This is utterly dissimilar to personal passwords. Public key certificates have limited validity because digital signatures cannot be revoked offline. The entire premise of a digital signature scheme and PKI is that you default distrust. Therefore, signers must renew instead of revoke, like a dead man’s switch. It doesn’t make sense to use this principle as a comparison for password security, because passwords are a secret used for access control, not authentication in the cryptographic sense of the term.
I think there is merit to the argument that public key authentication is better than passwords, but such a discussion should 1) include nuances, like the differences between authentication and access control, and 2) be mindful of cavets, especially with respect to usability. Under the current paradigm, passwords are not weak just because they do not share the same e.g. rotation characteristics as certificates, because they have very different use cases and threat models.
This isn’t correct. Password rotation is a function of desired cover time (how long you want to maintain confidentiality) and password strength (approximate entropy and complexity).
If you randomly generate a password with 20+ mixed case alphanumeric characters, it’s theoretically safe against offline brute forcing attempts for more time than the universe has existed. Statistically speaking, you gain virtually nothing by rotating such passwords unless you know they’ve been compromised. On the other hand, you impose a significant security liability through usability friction.
This was me a couple months ago. Had one password that I reused on a bunch of websites where I didn't particularly care about security.
Eventually decided to give them all stronger unique passwords (because why not) and it was a pretty easy process because the password manager could show me all the sites with duplicate passwords.
And theres some sites where random passwords just don't work because of dumb password rules so hand making them is easier. Also still nice to know when a password, randomly generated or not, is released out there in the wild.
well, let's say I run idiotService, and you login with a nice strong randomly generated passphrase, but since I'm idiotService, I just store it plaintext and check against it.. to make matters worse, some bad guy steals my password list, but I'm such an idiot I didn't even notice...
Troy hunt, in his ever-long quest of getting copies of these breaches, eventually gets a copy of all of my passwords and adds it to his database, and now suddenly, you the user get a warning, uhh.. this password is in the pwned-passwords DB... and now you know idiotService really is an idiot.
Because your generated "long and strong password" is not accepted in some sites, or cause problems or is just a PITA to type on mobile devices, or I can't copy and paste it for some reason or another, for example
Or because the password itself is leaked somehow (eg a DB of passwords that was stored incorrectly getting hacked, which happens with some degree of regularity). I use a "long and strong" password to lock a password manager, which itself generates long and strong unique passwords for each login (I use 1pw here, which is nice because it can also handle 2FA/rolling codes). I haven't yet found a better way of handling that at scale that isn't "write down your passwords on a piece of paper in clear-text".
I use a password manager and still have embarrassingly simple passwords for some things. The reason is that the most common place I'm "typing" this password is an obnoxious interface like a gaming console.
Lastpass has an awesome option when generating passwords for cases like this: "Make pronounceable". It will generate a password like "lickyusideno" (just generated that now) which is easy enough to remember between looking at the lastpass app on your phone and then typing it in through a console/netflix/etc interface.
I wrote a little HTML/JS app to generate pronounceable passwords which alternate left-and-right hands. Mainly I use it for my AD logins at work, which I A) have to enter numerous times per day and B) have to change every 60 days. The "pronounceable" part makes them easy to remember for the first couple of days, and then the "easy to type" part means muscle-memory takes over so that it's barely and inconvenience.
Data source is a python script which trolls through /usr/dict/words and then counts the occurrence of each three-letter alternating-hand combination, outputting the counts. To start I pick a letter with 1/26 odds, then filter the triplets based on first letter, then continuously pick triplets based on the last two selected letters.
(I think this amounts to a Markov chain but I've not studied them well enough to know for certain...)
1Password actually has the same feature. You can separate the words with a hyphen, space, period, comma or underscore on generation to make it more human readable.
All of the bad password traits are rewarded in this scenario. You want a password as short as possible, with as many repeating characters as possible, etc.
"Clicking the Check Password button will call out to Troy’s service and let you know if your password exists in his database. "
I think the point is to see if any password you've come up with (either generated in 1password or on your own) has been breached and you don't know it. If you do have unique passwords for everything and you see that it's there, then you would know what's been pwned.
2) get asked to help someone else at their machine
3) need to log-in to a remote resource under my own user to do something
4) password is in the password manager on my workstation on another floor
Solution? Should I:
* ask the person to give very exact and detailed instructions on what they need me to accomplish so that I can do that work from my own workstation?
* go up to my workstation and call the person who needs help and walk him through logging in as me?
* remote-login from their workstation to mine to copy/paste (and hope their workstation's clipboard is secure)?
* bring my password manager with me on my phone (and risk my passwords being pwned because phones are Not Secure)?
* write down 40 character password somewhere (stick-it note?) and hope I neither typo anything, nor allow others to read it, nor carelessly discard it?
* just use a password I made up and can easily remember?
I'm sure there's better solutions. Each one has their own annoyances.
Physical device small enough to be quickly stolen: Not Secure. (this is self-evident: physical access to device is Game Over)
Low battery requires plugging in a cable to charge; the cable may be a surreptitiously-installed data cable. I do not trust the hardware or software stack that handles the data cable to be secure.
Many apps "require" silly amounts of permissions to the phone before they'll install. Apps' ability to read what's on screen, to be notified of clipboard changes, to listen to sounds; all when not even in the foreground. On my computer, I can easily check what apps and background services are running. Not so easily on a phone.
(this is self-evident: physical access to device is Game Over)
This is just totally not true.
I'd wager a fair sum that passwords stored on an iPhone, behind a decent layer of security, are entirely better protected from physical access than on any general-purpose computer.
Passwords stored on a general purpose computer, behind a decent layer of security, are entirely better protected from physical access than on any phone I've ever used.
Copy/paste the needed password from your workstation to a text file on a secure USB key, then use the key to copy/paste it into the login on the other workstation and delete the file.
> * remote-login from their workstation to mine to copy/paste (and hope their workstation's clipboard is secure)?
This option also risks leaving around credentials to remote-login to your workstation.
No sense worrying about the workstation's clipboard-security though- if the workstation itself is pwned or intentionally bugged, the password will be at risk from a keylogger or network-sniffing proxy when it's typed in anyway, so no avoiding that risk.
Option B is to ask yourself whether a 40-character impossible-to-write-down-without-typos password, phones are Not Secure level of security-paranoia is worth the tradeoff of inconvenience (it may be, depending on the nature of your work).
Some passwords I need to memorise (e.g. the logon password for my primary machine), and others need to be input on devices where long, strong passwords would be unduly cumbersome (e.g. my Xbox/PSN accounts are never going to get the same strength I use elsewhere because typing long, mixed case + symbols passwords on a controller is a nightmare).
> The way they implemented this is nice, but seems a bit pointless to me.
I've always thought that the best way to build a rainbow table is to create a 'password checking service' like this and have people fill it with their own passwords.
The only way I can get a password that meets some of the more ridiculous "security" policies some places have is to go through the criteria and make one up myself.
I'm more concerned about people using weak master passwords for their password managers. It's a single point of failure in the security of every other password they have.
I do it because lastpass/1pw/bitwarden/etc all seem to generate random passwords which are hard to use manually. If they do a "pronounceable" one it's all lower case or doesn't mix case other than randomly or capitalizing the first letter. Many of us like some kind of variation on xkcd's password generator. I haven't seen an implementation that does it the way I like so I wrote my own. I have that generate a password and then I put it into bitwarden (or whatever I'm currently using). I thank myself when I have to manually type the password into a device because I can look at it and remember it long enough to type it one time.
Also, some "long and strong" passwords are too long and/or string for sites that have poor password requirements.
I'm not sure what your requirements are, but 1password optionally generates passes from words. Eg:
> fracas homily unsaddle bonus pueblo victim
I vastly prefer it.. by leagues. With that said, I rarely use it. For my feeling of security I want to use many word combos, but it's very common for password input services to limit the number of characters I can use. Some of them (shockingly often) even truncate the password and accept it anyway, so now I don't even know what my password is.
It is pointless to me too. Yet, one of my co-worker told me: "Because even if not using crazy long random generated passwords, using a different one for each login is still a step in the right direction, and being able to remember 200 discreet passwords is hard for almost anyone."
We just implemented this in-house today against our user logins, except we pulled the entire 30+GB data file locally, instead of doing the API callout like 1p does it.
So far no owned passwords have been found!
well, I used torrent, like he asks, if possible to please do.. But yes, thankfully he still provides a straight download thanks to CloudFare. We did it locally, because we are a regulated industry, and doing random calls out to the internet, especially from a authentication server, is all kinds of nightmare to make happen.
LOL. EXACTLY! :) No.. @ password time, we do the normal path PLUS we take the plaintext password, encrypt it with SHA1, see if it's in the pwned database, if it is, warn user. Then we throw the SHA1 away.
So sure, it's stored in memory as a SHA1 hash, briefly, but that same memory has the plaintext password...briefly so :)
Our normal auth path just attacks AD, so we use AD as the primary store for passwords.
After it's been in production for a while, and we see it's still working like gangbusters, then we will turn on that @ password change time, if it's in the DB, we will ban that password from being used. Probably in the next week or two, it depends.
I'm interested, but this looks like it sends the full hash to HIBP. Perhaps you could upgrade it to the improved-anonymity version where we only send the first 5 chars?
I use keepass, and I whipped up a quick script to look all the passwords in my keepass file against the hashes in the list. You have to download and unpack the file first.
I don't use the subscription service of 1PW, but it's impressive that they got this out so quickly after Troy Hunt released it.
I'd love to understand how they did this, especially given the additional security implications of this feature you would expect it to require reviewing, testing etc.
* Phase 1: Setup password checking site pretending to check passwords against stolen passwords. Steal all passwords inputted.
* Phase 2: ???
* Phase 3: Profit
(Downvoters, I'm only having fun, and yes I know this is a good source. But: Do be vigilant. It doesn't take a stretch of the imagination to suppose that this scenario could happen.)
For sure, this is possible. But Troy Hunt is well known, and using his new v2 API, at most only 5 characters of the sha1 hash is sent across.
Alternatively, like I did, you can download the 31GB file and do it all locally, and not involve network round trips.
1p is well known in the community for being pretty good with security, so the chances of them implementing this in a different way than they say they did would be severely damaging to their reputation. Once it comes out in local 1p apps, we can verify that they did do it the way they said they did.
You're only sending part of the hash here, the potential evil password-checking service wouldn't know who's sending the request or where this password is used. All he'd know is the originating IP address. I don't know a way to link a particular IP to an online service username, which would be major news.
Presumably in that case 1Password is sending the requests from their own servers, so the whole range of 1 million prefixes would be quickly explored, giving no information at all to the password-checking service.
I agree completely. You're sending a prefix which is good enough to reject 99.9999% of candidate passwords. Maybe you're fine sending that prefix to TroyHunt or to 1Password because you trust they won't try to use it against you.
I'm not passing judgement of whether they are trustworthy. But I do think it should have been mentioned in all the back-patting around "k-anonymity" exactly how useful or not the prefix would be in the hands of an attacker.
The argument that "the attacker won't know which user the prefix belongs to" is certainly a big qualifier that would make access to the prefixes less useful. Can we be certain that always holds true?
Certainly in the case of 1Password the user is sending their hash prefixes in a way that directly identifies the user's identity to 1Password, and anyone who can snoop on that communication. This is also true for anyone using the HIBO webform directly to submit their favorite passwords.
sqlite> select substr(hash,1, 5) as hashbeg, count(*) as count from pwned group by hashbeg;
# put result into hashcount table
sqlite> select avg(count) from hashcount;
478.397716142925
sqlite> select min(count) from hashcount;
381
So, I'm not sure I agree with you, if on avg almost 500 records are returned given the first 5 chars of the SHA1 hash across the 1/2 billion records.
But I do agree it helps with cracking the passwords, but seeing as how all of these passwords are BAD and are known to have leaked... cracking them again isn't the use-case, the bad people likely already have all these passwords in plain text.
The resolution of the discriminator has nothing to do with the strength of your password.
Having the first 20 bits of the hash certainly isn’t the same as having the whole thing, but the simple math says that only 1 in a million wrong guesses will match.
This is very powerful, for example, if you have a strong hash which you want to crack along with the first 5 characters of the SHA1 because then you only have to run the slow hash 1 in a million times.
It’s also very powerful if you want to do an online attack because you can narrow down your guesses quite significantly.
Lastly, if you are logging in with keys (random entropy encoded as human readable string) rather than passwords of course none of this concerns you in the slightest, nor do you have any use for this API in the slightest.
To state it another way, if you have 80 bits of entropy in your password, maybe no big deal to throw away 20 bits worth (but for what purpose?). However the average password has less than 30 bits of entropy, so throwing away 20 bits is a big deal.
The end result is there’s a lot of trust being placed in this API, and in particular the idea that services should be calling out to it as part of a login process, or that we should be training average users to test their passwords in a webform, that is concerning.
I'm only having fun but yes, I am sure it's a solid source. I have in fact inputted one of my weaker (common, low-impact forum-only) passwords there in the past. It was pwned.
”In future releases we’ll be adding this to Watchtower within the 1Password apps, so you can see your pwned passwords right in the 1Password app you use every day.”
"Clicking the Check Password button will call out to Troy’s service and let you know if your password exists in his database."
Wow, what a bunch of jerks. They didn't download the torrent and host the password database themselves for their commercial product? They instead make use of Troy's resource he's making available on his own dime.
The cost of this is actually paid for by Cloudflare as they've donated CDN services to aggressively cache the API response, of which there is only 1 million possible responses.
Plus in the comments they say it was only implemented this way to save time (it was done within 27 hours of Troy's service being announced) and Troy has publically supported this use.
Thanks for that explanation. It seemed like a real abuse of Troy's good will. I still hope they plan to migrate to their own hosted database quickly and not overstay their welcome.
I still love 1Password, but this treatment makes me unhappy.