Add feature - Troy Hunt password pwnage
I'm a 1Password user and want to suggest a feature. I don't have a forum account so I've set one up just to make a suggestion.
Troy Hunt, a Microsoft MVP, has released nearly 12GB of pwned passwords online. You can search them on his website or download them in ZIP format for local search. Because of the very large size Cloudflare have offered to cache them and they can be downloaded over a fast connection.
This is an excellent initiative by Troy and I'd like to see AgileBits incorporate this list of passwords into your WatchTower feature. I know the argument is that this would require the user's passwords to be sent the server but you could send a hash instead.
It'd improve security and would be a great addition!
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Thanks, I totally missed that! :)
0 -
Thank you for participating, @XIII! :+1:
@suggestfeature: I would also like to point out this reply from Brenty some time ago: We're really focused on not knowing anything about the sites our customers visit, so it's always something we need to consider.
Thank you for bringing this up, though. Discussion is always a good thing. :)
Cheers,
Greg0 -
@Greg, you've posted Brenty's comment but you've totally misunderstood what my point was.
This is not a list of sites; it's a list of passwords which have been compromised; thus if 1Password detected the use of an already compromised password (from that list) then the software would alert you.
It has nothing to do with "knowing anything about the sites our customers visit".
0 -
@suggestfeature: Thanks for clarifying. It could still be a privacy and security concern since users would have to send well-known (in this context) hashes of individual passwords for the server to compare. It's also going to be a processing/bandwidth issue for many users, since we're using 1Password to have a unique password for — in many cases — hundreds or thousands of websites. The great thing about Watchtower is that we simply set database entries with URL/date pairs, and the user can download the entire database in seconds. So the only information we get in that case is that there's (presumably) a 1Password user at that IP address making the request. We really don't want to know about individual users' passwords, and many people choose 1Password because of this. So while we can consider this, I hope you'll appreciate that it isn't something we can take lightly, as there are a lot of different factors involved, both in principle and in practice.
0 -
I understand that it's not something you can take lightly and it's only a suggestion at this stage but I think this would nicely complement the Watchtower feature.
It could be an optional feature called Unsafe Passwords or something along those lines. If optional and opt-in, it'd overcome any privacy concerns.
As you point out they are well-known passwords therefore the privacy risk is negligible but the corresponding security increase (of telling users that their password is known to be insecure) would be considerable.
If 1Password are concerned about bandwidth then the program could be set so that only passwords manually entered by the user are checked against the list. It'd be unnecessary to check any randomly generated passwords against the list and this would further enhance privacy as you wouldn't be sending the passwords in this scenario.
Another possible option is that you have a manual feature "Check my passwords against known insecure passwords" along with a warning that "Your passwords will be transmitted to our servers but we won't be able to decrypt any unique passwords".
The alternative is that your average user is kept in blissful ignorance of their own insecurity; a sadly all too common occurrence. 1Password may say that 'ignorance is bliss' and that's true but it doesn't help them improve their security.
0 -
I understand that it's not something you can take lightly and it's only a suggestion at this stage but I think this would nicely complement the Watchtower feature.
It could be an optional feature called Unsafe Passwords or something along those lines. If optional and opt-in, it'd overcome any privacy concerns.@suggestfeature: Again, I think you're looking at this from only one angle, and we have to consider others as well.
As you point out they are well-known passwords therefore the privacy risk is negligible but the corresponding security increase (of telling users that their password is known to be insecure) would be considerable.
The privacy concern is us getting a password or password hash from any 1Password user. That's not something we've ever done, and I've literally never heard anyone else suggest that we should. People expect using feature in 1Password to not pose a security or privacy risk, so I think it's something we'd need feedback from other users about, given such a dramatic shift.
If 1Password are concerned about bandwidth then the program could be set so that only passwords manually entered by the user are checked against the list. It'd be unnecessary to check any randomly generated passwords against the list and this would further enhance privacy as you wouldn't be sending the passwords in this scenario.
Another possible option is that you have a manual feature "Check my passwords against known insecure passwords" along with a warning that "Your passwords will be transmitted to our servers but we won't be able to decrypt any unique passwords".As I indicated earlier, that would be unprecedented, and goes against our principles of not data from 1Password users, which is important to many people both inside and outside of AgileBits. It's not something we're going to do today, or in the future without carefully evaluating the options and seeing if we can accomplish something similar using another method, much like Watchtower today.
And I think that, because you're dead-set on this particular method, you're overlooking the fact that Watchtower and other Security Audit features already cover much of the same ground already. If you have an account with a site which has been compromised, Watchtower can tell you. And "duplicate passwords" will let you see if you'd been reusing that anywhere else, so you can change it there too, even if that site has not been breached. And "weak passwords" will tell you if you have any which are not long, randomly generated ones which could easily be guessed, even if they were never exposed.
I agree that your proposed feature sounds really cool, especially to a nerd like me, but can you tell me what specific need it addresses? At this point we're talking about:
- Having the user opt-in to either download gigabytes of data to their device, or
- send passwords/hashes to AgileBits,
- to check them against the database either by direct comparison locally in automated fashion, or
- by manually entering them to be submitted for comparison with an online database...
And at that point, if we're talking about manually entering passwords, I'm not seeing how this would be different/better than using haveibeenpwned.com, which already provides this service and is completely unrelated to all of our most sensitive data we entrust to 1Password. For me personally, that's a benefit, as I can access the site completely anonymously and check a password which I'm then going to change anyway. It just sounds like we're expecting the user to jump through more hoops here (opting-in, etc.) for results they can essentially get with 1Password today.
The alternative is that your average user is kept in blissful ignorance of their own insecurity; a sadly all too common occurrence. 1Password may say that 'ignorance is bliss' and that's true but it doesn't help them improve their security.
You're the only one saying that, and I think it's pretty ridiculous. As mentioned multiple times already, this is something we'll consider, but going in circles here and making provocative statements isn't going to make us decide and/or release something hastily. I'm sorry I don't have a better answer for you right now, but it's something we'll have to evaluate.
0 -
Thank you for replying.
It's going to be my last post on the subject because judging from the tone of your reply I've somehow upset you although I didn't intend to. :( I know I'm just a customer and it was just a suggestion so we'll move on.
- It was only a suggestion. I can automate searching of my 1Password database by exporting it locally and then comparing with tools like Python. I was thinking of other 1Password users who aren't familiar with scripting languages. It makes no difference to me if it's not implemented.
- I did look at it from various angles - the suggestion that it be: opt-in or only for manually entered password or only run on demand. I also gave suggestions for reducing bandwidth.
- If 1Password users trust you enough to store their data in the cloud then checking hashes of manually entered passwords (subject to informed consent) should not be a massive leap into the unknown. You already do store users' passwords (I understand the technical details) but I'm talking here about trust. If people can trust you enough to not backdoor the closed source software then they should be able to trust you to send limited passwords (only if they want) to a secure server.
- I'm not "dead-set" on any particular method. I'm flexible.
- Watchtower is for known compromised websites, security audit only reports on the security of a password. A high entropy password for example could be on Troy's list because a website was compromised which used a bad hash (e.g. MD5) or didn't hash at all. Therefore his list provides something not matched by your other features.
- I don't suggest a user downloads the full database - you and I agree that'd be absurd. My suggestion was that a user's passwords be checked against the list (providing the user opts-in). If you use a sufficiently secure hash SHA-256, bcrypt, SCRYPT then you'd be unable to 'decrypt' the secure passwords but you'd be able to decrypt the insecure ones and therefore alert the user. I'm aware of computational resources etc
- Your other suggestion, about manually entering passwords, isn't one I'd recommend because a service like 'haveibeenpwned' is already out there.
You're the only one saying that, and I think it's pretty ridiculous. As mentioned multiple times already, this is something we'll consider, but going in circles here and making provocative statements isn't going to make us decide and/or release something hastily.
It wasn't intended to be a provocative statement nor did I put it out there to be ridiculed. I made the comment because for users who don't know their password/s are insecure (e.g. they don't know of Troy's site), the status quo means they'll continue to be ignorant of the fact their password/s may or may not have been leaked - and the site may not have been included in Watchtower and the password may have been otherwise secure (and passed the security audit).
I was initially trying to expand on my thoughts and didn't want to "going in circles", I didn't think I was considering I only replied once to your comment.
I think it's pointless me further contributing because I've clearly been misunderstood and my motivation for suggesting the feature was to protect users who use insecure passwords, not to start an argument.
0 -
@suggestfeature: Thanks for getting back to me. That's very generous of you under the circumstances. I am sorry about that. I'm not upset at all, but it's hard to convey tone accurately in text. I just got the impression that you were expecting this to be implemented, so I wanted to clarify the request, the problem we're trying to solve here, and also be realistic with regard to the different factors involved. I really didn't mean to discourage you from continuing this discussion. I'm glad you started it. I just think we need to identify exactly what we're trying to accomplish with a feature before adding it. I appreciate your followup comments. I think you make an excellent point:
I can automate searching of my 1Password database by exporting it locally and then comparing with tools like Python. I was thinking of other 1Password users who aren't familiar with scripting languages. It makes no difference to me if it's not implemented.
You're right. That's why we integrated Watchtower into the app: manually searching the site or creating scripts is not a good experience, and because of that almost no one would use it otherwise.
If 1Password users trust you enough to store their data in the cloud then checking hashes of manually entered passwords (subject to informed consent) should not be a massive leap into the unknown. You already do store users' passwords (I understand the technical details) but I'm talking here about trust. If people can trust you enough to not backdoor the closed source software then they should be able to trust you to send limited passwords (only if they want) to a secure server.
That's a fair point, as trust is fundamental. But we do not ever receive users' passwords, not even their account credentials when signing in to a 1Password.com account. With 1Password user data, all that is ever transmitted is an encrypted blob; and with 1Password.com credentials, only a SRP (Secure Remote Password) verifier is transmitted, so that the password never leaves the user's device, even in encrypted form. We really go to a lot of trouble to not have users sending us their passwords, and a lot of people are comfortable using 1Password expressly because of that, and how little in general we know about them.
Watchtower is for known compromised websites, security audit only reports on the security of a password. A high entropy password for example could be on Troy's list because a website was compromised which used a bad hash (e.g. MD5) or didn't hash at all. Therefore his list provides something not matched by your other features.
I guess this is where we disagree. I may be missing something, but it seems to me that knowing that the specific password for a website has been compromised is implicit in a breach that Watchtower informs you of. For instance,
- example.com is breached
- The data dump allows Troy Hunt to add the stolen passwords to his site
- At the same time, Watchtower is updated
- Watchtower informs me that I need to change my password for example.com
So there's overlap. Me seeing that this specific password has been compromised is irrelevant in this case, as I know it has been regardless due the breach. And if the data dump is not released, and I'm relying only on Watchtower, I'm still covered, even if I can never verify that the password itself was compromised, only the website. Better safe than sorry.
Your other suggestion, about manually entering passwords, isn't one I'd recommend because a service like 'haveibeenpwned' is already out there.
I probably misunderstood then. Earlier you said this:
If 1Password are concerned about bandwidth then the program could be set so that only passwords manually entered by the user are checked against the list.
I thought you were proposing manually entering passwords to be checked.
It wasn't intended to be a provocative statement nor did I put it out there to be ridiculed. I made the comment because for users who don't know their password/s are insecure (e.g. they don't know of Troy's site), the status quo means they'll continue to be ignorant of the fact their password/s may or may not have been leaked - and the site may not have been included in Watchtower and the password may have been otherwise secure (and passed the security audit).
It really sounded to me like you were making some fairly sweeping statements about the competency of users in general. I apologize for misunderstanding.
To be clear, if a website is breached, whether or not the stolen data is released publicly (so it can then be added to haveibeenpwned.com) we still add it to Watchtower to inform users.
I was initially trying to expand on my thoughts and didn't want to "going in circles", I didn't think I was considering I only replied once to your comment.
That's my fault. I appreciate you taking the time to correct me. I think maybe the larger point we're circling around here is that Watchtower and Security Audit in general have room for improvement, for visibility and usability.
I think it's pointless me further contributing because I've clearly been misunderstood and my motivation for suggesting the feature was to protect users who use insecure passwords, not to start an argument.
I'm really sorry about that. I appreciate your comments here, especially now that we're (I hope, with your help) on the same page. I understand why you may not want to, but I do hope that if you have other thoughts on this you'll accept my apology and we can hash things out further. I'm listening, and I know the rest of the team is too, but I just want to make sure that I don't give you the impression that this is something we're going to be able to work on right away. However, that doesn't mean it isn't worth discussing, and that your feedback isn't valuable and appreciated, and I'm sorry if my earlier comments gave you that impression. :(
0 -
@suggestfeature: I'm not sure I understand this part:
If you use a sufficiently secure hash SHA-256, bcrypt, SCRYPT then you'd be unable to 'decrypt' the secure passwords but you'd be able to decrypt the insecure ones and therefore alert the user.
I understand being unable to decrypt (secure) hashes, but why would you be able to decrypt insecure passwords?
(I would understand matching hashes, but I think Troy only offers SHA-1 hashes, no others, like you mention?)
How would this work?
0 -
Brenty
I'm really sorry about that. I appreciate your comments here, especially now that we're (I hope, with your help) on the same page. I understand why you may not want to, but I do hope that if you have other thoughts on this you'll accept my apology and we can hash things out further.
It seems like we were at cross–purposes; neither of us had understood what the other was saying and there was an element of frustration.
Thank you for the apology, I'm sorry that I wasn't more clear in my original post and we probably wouldn't have had such a disagreement.
But we do not ever receive users' passwords, not even their account credentials when signing in to a 1Password.com account. With 1Password user data, all that is ever transmitted is an encrypted blob; and with 1Password.com credentials, only a SRP (Secure Remote Password) verifier is transmitted, so that the password never leaves the user's device, even in encrypted form.
I appreciate that (technically speaking) the SRP serves to increase the entropy and to act as a hybrid 'second step' but my point, as you alluded to, is one of trust. We as users have to blindly trust 1Password to do what you say.
Okay I could use Wireshark combined with a fake certificate root authority to MITM my connection so that I may see what is transmitted but this is well beyond the capability of the average user.
I could choose to verify that 1Password is acting as it should by debugging it but this isn't something I think I need to do and it probably against your TOS. I have no reason to believe that AgileBits are acting maliciously. If you were an American company I'd be much more suspicious because of the well-known US interception programs and their ability to compel companies to secretly provide user data.
This takes me back to my original point - you store our passwords on your server (in an encrypted blob) and we have to trust you not to do something evil such as intercepting the password and SRP - we both accept this is technically possible with the relevant modifications. It's nice security in theory (and practice) but it hinges on trust and nothing more.
If as users we trust you then it's fair for users to trust you to check insecure passwords against the Troy list in a secure manner.
I guess this is where we disagree. I may be missing something, but it seems to me that knowing that the specific password for a website has been compromised is implicit in a breach that Watchtower informs you of.
I believe Troy has scraped the passwords from a number of sources and not just from known data breaches, e.g. password dictionaries.
I see your point about Watchtower and it'd make perfect sense if the Troy list only contained passwords from those data breaches, i.e. all you'd need to know is which sites were breached and then you can alert the user as you do at the minute.
However if he's scraped them together from multiple sources (not all from known data breaches) then Watchtower cannot help.
Also if several users are using an insecure password which happens to be on Troy's list and only one 1Password user is a member of the breached site then Watchtower will only alert the user with the credentials stored and not the other users who may be using that password on other sites. Of course people should be using unique passwords, particularly with 1Password, but the reality is many don't especially if they're migrating to your service.
I probably misunderstood then. Earlier you said this:
If 1Password are concerned about bandwidth then the program could be set so that only passwords manually entered by the user are checked against the list.
I thought you were proposing manually entering passwords to be checked.
I was proposing that a user selects entries from their list, e.g. CTRL + Click, and then press a CHECK PASSWORD SECURITY button. Therefore the suggestion is that a user is given an option to check the security of their passwords upon demand instead of automatically if server traffic is a concern.
XIII
I understand being unable to decrypt (secure) hashes, but why would you be able to decrypt insecure passwords?
(I would understand matching hashes, but I think Troy only offers SHA-1 hashes, no others, like you mention?)
How would this work?
Excellent question! It can be worked by removing the salt so that you get a consistent/reproducible output. It'd be extraordinarily difficult to 'decrypt' a secure password but it'd be trivial to match the hash of a known insecure password.
If AgileBits were to use bcrypt/scrypt to hash a user's passwords then, assuming no salt was added, the passwords would be uploaded to a server, checked against the list and then a message sent to the user indicator all clear or warning of the insecure password. Immediately after the output message is transmitted the password hashes would be wiped from server memory.
Assuming AgileBits aren't acting maliciously (we have to assume this in all scenarios) then even if a hacker broke into the server he'd be unable to get the plaintext password (from the secure password set) because bcrypt/scrypt is extremely slow. Naturally by removing the salt you'd make it slightly easier mathematically but for all practical purposes it'd be impossible to break the secure passwords.
If AgileBits were acting maliciously then all bets are off, they could just extract the passwords as plaintext as a I explained earlier.
0 -
To pipe in - I'm not a fan of these 'enter your password and see if your password has be pwned' sites. It wouldn't surprise me if you entered your password, were told you are safe, but their list is now updated by one additional password - yours.
0 -
@architect1337: Very true. While Troy is a well-respected security expert and, I think, worthy of trust, I have no doubt that there are others out there harvesting passwords in this fashion. It is nice, though, that giving just a password doesn't tell you anything about where/how it could be used — not that we want to rely on that, but it's another thing to consider.
0 -
@suggestfeature: Thank you. That's very gracious of you. Likewise, you make a lot of great points about trust. I think that may be a separate discussion entirely though, perhaps is a bit too broad for this topic. If you don't mind, I'd like to focus on this specific feature request to see if there's something actionable here. I think there's potential.
I believe Troy has scraped the passwords from a number of sources and not just from known data breaches, e.g. password dictionaries. [...] However if he's scraped them together from multiple sources (not all from known data breaches) then Watchtower cannot help.
Ah, that's interesting. You're right of course, but I do think that at that point we're talking about weak passwords. Maybe there's something I'm overlooking. Can we break it down into examples/categories? I'm thinking something like this:
- Weak passwords (short, dictionary, etc.)
- Compromised passwords
- Reused passwords
It may be that it's too late in my day and I'm missing something obvious, so let me know if you'd add to that list. But to me it seems like 1 and 3 are covered by Security Audit, with Watchtower in particular filling the number 2 slot. However, I do see that one could make a case that "reused passwords" and "duplicate passwords" are not necessarily the same thing, depending on the context. So we may have a #4 there at least.
Also if several users are using an insecure password which happens to be on Troy's list and only one 1Password user is a member of the breached site then Watchtower will only alert the user with the credentials stored and not the other users who may be using that password on other sites. Of course people should be using unique passwords, particularly with 1Password, but the reality is many don't especially if they're migrating to your service.
Totally! That's why I'm really interested in seeing if we can hammer out the details. Even if it doesn't end up looking quite like what we're discussing here, we would like to overhaul Security Audit to make it more useful and accessible. And there's good stuff here if we can break it down I think. :)
0 -
To pipe in - I'm not a fan of these 'enter your password and see if your password has be pwned' sites. It wouldn't surprise me if you entered your password, were told you are safe, but their list is now updated by one additional password - yours.
Troy makes this point too; don't enter your password on an untrusted site. In my opinion Troy can be trusted but unless you know him personally (or you know me and rely upon my judgement) then you shouldn't blindly trust him. Trust but verify, where possible.
Now you could download the lists yourself but that requires a lot of bandwidth and a text editor capable of opening them! Then you've got the hassle of comparing them against your database.
That's why I'm in favour of 1Password implementing it because as users we already trust AgileBits with our passwords, subject to the earlier caveats thus it wouldn't require any change to our present trust model.
Ah, that's interesting. You're right of course, but I do think that at that point we're talking about weak passwords. Maybe there's something I'm overlooking. Can we break it down into examples/categories? I'm thinking something like this:
Weak passwords (short, dictionary, etc.)
Compromised passwords
Reused passwordsI'd say:
- Weak passwords Security audit helps here (but not for Windows users, yet!) Troy's list may help here
- Known provenance compromised passwords (e.g. Ashley Madison) Watchtower may help here Troy's list may help here
- Unknown provenance compromised passwords (found on anonymous pastes) Watchtower doesn't help here Troy's list helps here
- Reused passwords Security audit helps here
- Strong passwords that are coincidentally used by other victims of a data breach (small chance but possible) Troy's list helps here
Weak passwords may not necessarily be covered by Security Audit if it's something like "Correct horse battery staple" (I've not tried that) or something that 1Password thinks is secure but in reality isn't.
I have a gut instinct there's probably a sixth or seventh category but I can't think of them off hand.
0 -
Hey @suggestfeature!
Troy makes this point too; don't enter your password on an untrusted site.
Always wise counsel. I had similar thoughts as others about checking my passwords when this database came out. I personally chose to trust that it's unlikely my generated passwords are on this list and move on, but it's true we can't guarantee your generated password won't be on that list. After all, it's conceivable (if unlikely) that a password identical to your generated password was compromised. Password strength doesn't matter as much in a breach similar to the one Target found itself dealing with a while back where information (albeit credit card numbers and not passwords, in Target's case) were stored in plain text and stolen. Password strength wouldn't be a factor here.
Weak passwords Security audit helps here (but not for Windows users, yet!) Troy's list may help here
I think Security Audit is the better bet here and Windows users can always check out their password's strength on 1Password.com. Whether or not your weak password is on Troy's list, it remains more vulnerable than a strong one, so step one will always be a better password, whether your weak password has been compromised elsewhere or not.
Strong passwords that are coincidentally used by other victims of a data breach (small chance but possible) Troy's list helps here
I'm going out of order, but you made my next point for me here. I'd say the list is of more use, as you point out, when you've already got a strong password and are worried less about that password being guessed by brute force and more so that it's already out in the world somewhere. In this case, your concern is that it's likely to be used in a more atypical brute force attack that tries known passwords in conjunction with known e-mail addresses, for example, rather than a systemic method of guessing yours specifically. This brings us nicely to ...
Known provenance compromised passwords (e.g. Ashley Madison) Watchtower may help here Troy's list may help here
Unknown provenance compromised passwords (found on anonymous pastes) Watchtower doesn't help here Troy's list helps hereTheses are the two where the list may be of most use, in my opinion. That said, how to use the list is the more important question. Troy himself recommends that services use this list rather than individual consumers. So, for example, you create an Amazon account and choose a password. Amazon will then reject your password and prompt you to choose a different one if it's on Troy's list. For 1Password, following Troy's recommendation would mostly likely involve only checking your Master Password against the list when you create your account. Responsibility for checking your generated passwords used on other sites would then fall to those sites.
All of that said, I imagine you're seeking something similar out of the password generator (or at least, a configuration for the password generator that purposefully avoids the passwords on the list). I'm not aware of any specific plans at this point to implement this sort of feature. In fact, I can't even say whether or not this is feasible. I don't know enough about the inner workings of the password generator to make a guess and I long ago learned that building features like this is almost always harder than I think it is, but it's something worth bringing up to those who can determine if it's feasible. That much, I'd be happy to do. :chuffed:
The other choice, as I believe you and others have mentioned, would be for Watchtower (or perhaps a new function entirely) to query Troy's list (and perhaps others, where available) for your passwords and notify you of those that match passwords on the list(s). This, I can say for sure, would be a difficult tasks. Troy's list includes hundreds of millions of passwords on its own and the way that Watchtower works without letting us know your passwords is it downloads the list of compromised sites to your local device and references your logins locally. As you mentioned, saving that list would be a bandwidth hog and updating an even more massive list as new passwords are released would only exacerbate this problem. As Brenty mentioned, this is a concern not just for our customers, but for us as well since our servers would share this burden. There may be a way to accomplish this without sharing your passwords with us that wouldn't excessively strain servers or customer bandwidth, but it would require a brighter mind than my own to figure that out and, again, I can't say for certain it is a possibility.
None of this is to say there's no way for us to use this list. There may well be, I'm just not the person who's going to figure it out. Assuming I've articulated your request well enough here (and do let me know if I haven't), I'd be happy to pass this along to our security team so that those brighter minds I talked about can give it a ponder. I can never make any guarantees, but this has undoubtedly been a conversation worth having (and an interesting one to read as well). I also welcome any additional thoughts you have. Judging by your prior responses, I'd say you've got a better handle on this than I do, so I'm sure your thoughts will be of help as well. :chuffed:
0 -
I think Security Audit is the better bet here and Windows users can always check out their password's strength on 1Password.com. Whether or not your weak password is on Troy's list, it remains more vulnerable than a strong one, so step one will always be a better password, whether your weak password has been compromised elsewhere or not.
Could you tell me where in 1Password.com is the place to check out password strength? As far as I am concerned, Security Audit elsewhere hasn't yet reached parity with 1Password for Mac's Security Audit.
0 -
Thanks! @bundtkate.
It is a challenge to access 1Password.com when I am out and about and even when I'm desk bound, I don't often think of it.
0 -
Assuming I've articulated your request well enough here (and do let me know if I haven't), I'd be happy to pass this along to our security team so that those brighter minds I talked about can give it a ponder.
Yes, please do pass it on for their consideration.
My plan is that (assuming AgileBits implement this feature) whenever a user manually types in a password / copies and pastes / imports into 1Password, it checks against the Troy list.
For randomly generated passwords it'd be unnecessary because the likelihood of
45qGqixE<3,.MwvL@f*8Nd8X|DHe4"pW{~!cdTBdu[q<,c+n{u.IP_xJ0i5_$/+ES4k#_^^M~f9N$"OjaB/1Tappearing in the Troy list is extremely unlikely. However having a button to allow the user to check it if he really wants would be great.
0 -
@suggestfeature Happy to do it and thanks for the chat. :+1: If you have further thoughts, too, feel free to share. We're always happy to hear new ideas about how to make 1Password work better for you. :chuffed:
0 -
Hi
I would hope that nested tags can be implemented eventually but the sooner the better! Tags and Security needs improvement.
Some of my logins have appeared in Troy Hunt's site but I have also terminated a bunch of unwanted logins as well.
0 -
Yep, more Security Audit features and improvements for tags are on our list as well. ;)
0 -
Great! :)
0 -
:sunglasses: :+1:
0 -
This content has been removed.
-
@JamesHenderson: I can definitely see how it would help a lot of people, but in that case I'm not sure it would offer anything actionable for your father. If he's using the same password for many sites, it would be really overwhelming to have to change all of them suddenly if it was stolen from one. Definitely something we'll take into account as we develop future iterations of Security Audit though.
This isn't going to work for everyone, but some folks help manage their loved ones' data using a shared vault in 1Password Families. That way they can keep a lookout for duplicate/weak passwords and Watchtower alerts, where others might not be as diligent with this. There's definitely a privacy and social issue with that, so it isn't going to be a good option for everyone. But I know it's helped others.
0 -
This content has been removed.
-
Watchtower lets you know if a domain has been breached, this lets you know password has been breached specifically. ...still a very good idea in my opinion.
Indeed. Thanks for the feedback. :)
Ben
0
