If I read this article correctly, the headline should actually be: How I made LastPass give me all MY passwords
Update: after a few answers to my badly thought through comment, I now feel enlightened. The attack scenario is a malicious web site which can gobble up my passwords. Thanks
My interpretation is. How I could create a web page that give ME all the commonly used site's passwords for ANY last pass visitor who has autofill enabled.
So no, I don't think it will only give you your own passwords.
If you where using LastPass, and visited any page controlled by an attacker on any domain, they could get your passwords to all sites that they tested for, for example twitter, gmail etc.
(to save a click: Tavis Ormandy: "Are people really using this lastpass thing? I took a quick look and can see a bunch of obvious critical problems. I'll send a report asap.")
I'm generally very sympathetic to regex bugs (especially in a language like JavaScript where you don't get nice expanded multiline regexes with comments), but I am wondering why they went with a regex in the first place. Did they decide `document.location.host` was too brittle for some reason?
You could have just linked to http://verbalexpressions.github.io instead of spamming all the repositories. Also, about half of them are out of date by 3 or more years.
Exactly... I probably could have posted less of them but in an era of TLDR it was easy enough to just post the list and let the uninterested scroll past and ignore it. That I have down votes for pointing out how practically no developers are without an option to guard against poorly written regular expressions, feels somewhat overkill.
I don't see how this would have prevented this problem. The issue was not that regular expressions were "too hard" for the lastpass team, but that URLs are hard to parse correctly. To put it another way, if you don't know how to parse a URL correctly, you'll probably write an incorrect parser no matter what parsing tool you use. That's why you generally shouldn't write parsers for URLs.
Not using `document.location.host` stood out to me too. I think the takeaway here is don't use regex unless you absolutely have to and don't use it to parse things that have rigorous standards describing them. Emails, phone numbers, URLs come to mind.
I once came across a bug in a codebase I inherited that parsed URI-references from HTML documents. That bug was caused by using that very same regular expression.
The string "foo" correctly gets parsed as a path (group 5). However the string "foo;key:value" gets parsed as a "foo;key" scheme (group 1,2) and a "bar" path (group 5) by the regular expression, but as a path if you follow the grammar.
I'm not sympathetic to regex bugs where they're being used to parse untrusted user input which is then later used to do something important (like, say, pick which URL to submit credentials to). They're way too easy to cock up for anything security-related.
It stores your data locally, is suprisingly easy to use and relies on battle tested GPG.
From the website: "The community has even produced a cross-platform GUI client, an Android app, an iOS app, a Firefox plugin, a Windows client, a pretty Python QML app, a nice Go GUI app, an interactive console UI, Alfred integration (1) (2) (3), a dmenu script, OS X integration, git credential integration, and even an emacs package."
If safety is your primary concern though, stick with just the command line client, which is a Bash script most HN-readers will be able to follow to the letter. It in turn uses GnuPG.
The lack of integration then with the rest of the OS is actually a security benefit.
I memorised a very simple algorithm to construct passwords from the domain name of a site. Then I concatenate that with one of three fixed portions depending on how important I view the site (e.g. banks get the most secure one, then gmail, then everything else).
It works pretty well. Different password for each site, I only have to remember a few things, and it would take several compromises (and a weirdly dedicated attacker) to work out my algorithm.
For example, my 'insecure' fixed part might be 'Tenk5$' (I recommend including uppercase, lowercase, a number and a symbol in that part to get around idiotic password requirements). Then my algorithm could be 'the last 5 letters backwards, skip the first vowel'. In which case my password for HN would be 'Tenk5$rtani'.
Problem is, that not all sites use the same style of passwort.
Some need Lower-/Uppercase, some with numbers, some with special Chars, some restrict to minimum of x chars, some use a maximum.
Your system works not for all things, i use a similar system, but store a bunch of passwords with last pass.
Only really important passwords are in my head.
Yes, occasionally sites don't allow it, but I've found if you use at least one of: uppercase, lowercase, numbers and symbols, and have a length of around 10, then it will go through virtually all sites.
I keep meaning to collate idiotic password rules so you can see for sure which patterns work in all of them, but I've never got around to it.
I use a method like that, but the result of that step then goes through PwdHash (whose code is small enough to inspect for naughtiness) so that multiple web sites wouldn't expose the scheme.
password reuse < own memory/manual storage < synced unencrypted 3rd party storage < synced encrypted 3rd party storage < custom encrypted storage < some custom crazy HSM which doesn't allow you to get more than X passwords per minute and notifies you on each get()
There's another dimension for cross-platform support somewhere in there. At the moment if you want your passwords saved and shared between desktops and mobiles, the best solution I'm aware of is 1password with separate sync (dropbox/icloud) - and you're still trusting the 1password app. You can go further, but you're starting to destroy usability on the way. Lastpass / 1password is still a valid choice that's better than many alternatives.
Perhaps, but this particular exploit doesn't target the fact your passwords are stored in the cloud.
It targets the local autofill functionality in the browser, so it could conceivably have occurred in any password manager with browser/autofill integration. Including those that use a local password store.
Yes, it's exactly the equivalent of someone finding a bug with the auto-password fill functionality in Chrome or Firefox or IE to trick the browser into filling in a password on an unrelated site.
What's happening is that this extension auto filling the password in unintended sites. Where it is getting passwords from (offline or from cloud) is immaterial for this case.
It happens at the point that the browser functionality interacts with a webpage on the internet that is controlled by a third-party. A well-written autofill function will strictly only allow the 3rd-party website code to access passwords for logging into that domain - the Lastpass allows it to capture passwords for other domains.
This bug could easily occur in Chrome/Firefox's built-in password manager autofill, though I must admit I have slightly more implicit trust of the developers behind Chrome/Firefox than of Lastpass (instinctively; this may well be unwarranted).
Please correct me if I am mistaken, but couldn't this have been implemented into an iframe that when ran could send the passwords to another remote server?
If so, I am a little taken back by LastPass only offering $1,000 to the researcher that found and reported it for fixing. He or she could have taken a different path and resulted in this being used in some complex targeted attack against tech corporations via short-url redirect interstitial pages, or an ad network's javascript, etc. Given the potential damage, I'd say there is a missing zero or two on that reward amount, in my opinion.
I was surprised by them giving such a tiny amount too. The potential damage to their users here is staggering. If this was used to grab someone's twitter,facebook,email,linkedin an attacker could take full control of their online presence :S
Yes, my thoughts exactly. He could had made 100x that money on the black market, so no wonder we still have problems with 0days traded there.
How long would you work for $1,000? Some days, a week, two? If you spend more than a week on this problem it seems not worth to report it... On the other hand, if you set the incentive for bug bounty too high I imagine all sorts of cranks pop up, that want to show off bugs that are not there, and resources will be bound to this task -- they have to be verified, and analyzed even if its a bogus report (and in the worst case it will not accomplish anything).
Oh, no - I mean, if you want to reward people fairly, but not get a stampede to your door, tell them to report a smaller bounty than was received. They can spread private word to their network (presumably, other people who are going to actually be correct) but still provide hooks to the public.
Probably doesn't work out, but it's what came to mind as a way to deal with the balancing act.
> How long would you work for $1,000? Some days, a week, two?
You might not work for long on a $1,000 problem, but other people sure will. College or high school students, people in a country with low salaries such as Ukraine...
People find and disclose bugs regularly even where there isn't a bounty. Most (at least 99.99%) developers don't want to see a useful, successful product fail even if they can personally gain from it. The likelihood that an exploit for Lastpass will be discovered by an attacker and sold to a nefarious actor is very small.
Further to that though, we now know that this problem is fixed in LastPass. We don't know about other password managers. To that end, LastPass is now a better option than it's rivals.
To that end, LastPass is now a better option than it's rivals.
Only when you believe that all password managers are equally secure from the start.
There are many reasons to believe that this is not the case. Storing passwords in a cloud service is quite a red flag. Then there is a former employee stating on Twitter that part of the codebase is very neglected:
I never understood why security-conscious people would choose to use a service (e.g. Lastpass) that stores all of your passwords in the cloud. Why not just use KeePass instead? Yes, it's a little bit more hassle, but all of the other password managers have been subject to serious exploits like the OPs that put people's data at serious risk of compromise.
I have become a bit of a skeptic -- we know that a problem like this existed in the code-base and is now fixed. So, should we then conclude that LastPass is now "more secure" because of it, or is the existence of this face-palm bug in production code actually evidence that LassPass is "less secure"? Certainly I would not go so far as to claim that this bugfix somehow makes LassPass a better option than its rivals.
I put more/less secure in scare quotes, because my point is really that fixing one particular bug certainly closes that one particular attack vector, but security is not a progress bar that goes from 0 to 100.
What this write-up does in my mind is really highlight the risks that come along with using a complex piece of software to manage your passwords. We tell users they can use password managers to safeguard their passwords and increase their security. We talk a lot about the usability trade-offs which password managers entail, but perhaps not as much about the security trade-offs!
Bounties aren't just monetary motivation - they show that the company understands security and responsible disclosure. For example, I've found pretty bad flaws in some white label web-based CCTV DVR software (privilege escalation and session hijacking). I went to the company website and couldn't even find a technical support contact. Given there's no bug bounty or other evidence they take security seriously, I don't want to risk sending this to the wrong person and receiving legal threats etc so it will remain undisclosed.
> Further to that though, we now know that this problem is fixed in LastPass. We don't know about other password managers.
Um...it was a really stupid mistake. Writing your own bug-prone regex here instead of using an existing, trustworthy function is just really bad. Especially when the consequences of a bug mean a hacker can steal someone's passwords.
You should really hope that any company that prides itself (and bases itself) on security would never release this bug. It absolutely lowers the reputation of lastpass.
I wish I could upvote more than once. :-) Good on you, great reporting and all. Thanks for keeping my passwords more secure! And yes, I need Google Authenticator to log into my Lastpass.
I think paying only $1000 for a potentially company-imploding bug like that is incredibly short sighted.
It's far too low to motivate a lot of people to look for bugs, and to me suggests they're not serious about protecting their reputation if someone does find such a company-destroying bug.
HN has weird beliefs about the company-imploding properties of all sorts of bugs, from this to CSRFs that let you delete photos from Facebook. After all, a competitor could use it to erase all the photos on Facebook and then take over the market!
That was an actual argument on a thread about Facebook underpaying bounties.
To be fair, this bug is pretty nasty because it allows anyone to get all your stored passwords. That's like the core business of LastPass. LastPass leaking your login credentials for e.g. online banking is really not comparable to deleting Facebook photos.
How does paying extra money address the underlying concern that LastPass has absolutely trivial regex bugs that entirely defeat the security of the product? I agree that the bug is terrible, but the bounty and the impact of the bug to the company are largely orthogonal, unless the bounty includes a confidentiality term.
I guess the point people (including me) are making is that it should pay off to do the right thing and report a bug that is capable of killing your (core) business. While OP obviously is a honourable person, others might not be and are more interested in getting money than doing the right thing.
Of course it's illegal/wrong to sell an exploit to third parties, but that doesn't stop people from doing illegal things as long as they get money for it. You just don't know about the issues that are sold because that's obviously not going public.
This doesn't make any sense logically. We don't need to pay people to prevent them from committing felonies. The suggestion that we do is actually pretty offensive to people who find vulnerabilities. Most of us --- in fact, the overwhelming majority of us --- are not torn at all about whether we should sell flaws to the black market.
(This is of course orthogonal to the fact that the black market does not want these vulnerabilities.)
No, you pay people to bother looking in the first place.
Criminals will always be looking, but the odds of finding vulns against a company that pays decent bounties should be far lower than against one paying a pittance, since more people should be looking due to the greater potential reward.
Also, in this case, I think that the amount of damage the company has avoided due to the vuln leaking through non-responsible disclosure is far more than $1000. Deleting photos on FB is nowhere near the same class of seriousness.
The company STORES PASSWORDS. Leaking them is serious.
And somebody looked, so clearly the bounty worked! But the cost to find a bug has practically nothing to do with the impact of the bug. The incentive is to find bugs, not a particular world ending bug.
I am absolutely OK with the idea that you'd stop using LastPass because they have a bug this dumb. I'm even OK with you believing that LastPass should pay more than other companies because they are so clearly reliant on external researchers to work on spec to find the simplest possible flaws in their code.
The only problem I have is with the virulently bogus meme that companies should pay more for vulnerabilities because otherwise the "black market" will outbid them. No:
* The "black market" does not in fact want these vulnerabilities.
* Finding a vulnerability and then not using it to to enter into a criminal conspiracy simply isn't praiseworthy, and reasonable people don't have to paid not to do that. It's hard enough to do this kind of work in a society that believes there's something sketchy about finding vulnerabilities at all, without the constant chatter about how maybe they could just make a living by enabling crime.
* The argument doesn't even make logical sense. If the vulnerability is easy to find and exploit (as this one was), then no matter how severe it is, it doesn't command a high price because you could spend less money to independently rediscover it. Moreover, there are surely many other vulnerabilities to be found in the same target. The economics of the argument are all wrong.
So you don't believe there are blackhats out there? Because somebody has to be breaching online services and it's rather unlikely it's a godly entity doing that.
Felonies exist and people still commit them. Should they? God no. But people with a lower moral code exist and they can be flipped to do "good work" if there's enough money for them (and I think you should get more money in general for your important work anyway). I find the notion of your profession only consisting of good people highly offending to the rest of the world.
This is a crazy argument. HN is a community populated in large part by software developers, most of whom will at many different times in their careers ship vulnerable code they wrote. You're saying that if you start a new company, you should either (a) get your code absolutely perfect, which nobody ever manages to do, including people who go to great expense to try, or (b) be held hostage by extortion schemes to pay greater sums for vulnerabilities lest the discoverers exploit them to cause the most possible damage to your company.
You know who does fine in a world where that's the norm? Facebook. No matter where vulnerabilities get valued at, they will be a rounding error expense to Facebook.
You know who does not do fine in that world? Anyone smaller than Facebook.
Thankfully, that's not the norm in the real world. Unfortunately, the real norm is: if you pay a bounty at all, random people on Twitter and message boards will claim you're being negligent by not paying more for them. The lesson then is: don't offer a bug bounty. All you're doing is attracting negative attention.
You know who does fine in the real world where that's the norm? Apple and Cisco. Really, so does Facebook, despite the bullshit flak they take for their bounties.
You know who does not do fine in the real world? End-users.
The fact that LastPass consider that a flaw in their system that could have put them on their knees is only worth 1K is quite frightening if you are relying on them for your security.
Why not? I've been using it for about a year now (switched from LastPass) and haven't had any issues. Kind of miss the in-browser features of LastPass, but seeing as how those are what's being exploited, maybe not so much!
There are browser extensions that work with KeePass. This LastPass vulnerability makes me wonder, too. I wish the KeePass site would be 100% HTTPS, though, but the maintainer is a jerk in that regard.
That's a very bad recommendation. Very few people are capable of remembering unique 10-character passwords for each site. I have like 100 passwords and accounts for various systems and I'm certainly not able to remember each of them. So either I start reusing passwords or I use a password manager.
I switched to 1Password after Lastpass got acquired. I obviously have no special knowledge how secure it is but it's serving me well. OSX browser integration excellent, iOS integration mediocre.
How easy is it to migrate from Laspass to 1Password? I've had the worst experience with their tech support (reported 2 bugs that have both been scrapped as WONT FIX) and really don't want to support them as a premium subscriber anymore.
If you encounter any trouble please write into support at agilebits dot com and mention "Kyle" somewhere in the body of the email and I'll get notified. You should be fine though, but every once in awhile we have someone encounter trouble with the import from LastPass.
I checked out the pricing model and didn't see anything that made sense to me as an individual user. Is there any plan for an affordable individual plan (in the range of 10-20$/ year)?
As a Mac/IOS user, I don't see myself shelling out 60$ for a desktop license and then another 10$ for an IOS license on top of it. I'm sure your profit margin is great, don't get me wrong, but as a buyer that is just overkill.
The individual plan is the lowest cost subscription option, and standalone is an option if you would like to try to spread the cost out between releases, but you would have to pay for any major upgrades as those are not included.
I'd say many people don't need the Pro features in the iOS version, it's possible that maybe you won't either? Depends on how you use it I guess. Probably the biggest reason to get the Pro features is multiple vault support (you can add additional vaults that were created from the desktop versions). With the free version you only get the one vault.
If you use the app like most people, you'll be using it dozens of times a day. Even if it's in small interactions those do add up. I've been trying to convince the team to add some sort of individual statistics that were stored locally for users to see, but I suspect this would probably help you decide that regardless of price it would be worth while :)
In the end, the choice is yours though. We certainly want to hit the price point for all users that we can, but we do have to keep the lights on or the product disappears. We aren't priced at a point where we're trying to acquire users in bulk so we can sell to another company. AgileBits is privately owned and has never taken outside funding. Something to be aware of when you're talking pricing I suppose. At least one factor.
I appreciate the honest response. I couldn't find an easy link on mobile to explain what those Pro features were and it sounds like I don't need them after all. I just need to be able to share a database of passwords between my few devices for personal use.
Purchasing 1Password for 65$ gets the current major release with no updates?
Subscribing to 1Password Families for 5$/month:
Lets me sync passwords between all of my desktops and phones?
Can I sync an encrypted password database or is this done as a hosted cloud solution by 1Password?
Sorry for the delay in response here. I eventually had to go do some of my regular duties and that meant closing the web browser at some point yesterday :)
$65 gets you a single license for Mac and Windows. This can be installed on multiple Macs or PCs you own, but is generally for 1 single person.
You get all updates to 1Password 6 for Mac for free, and any updates to 1Password 4 for Windows for free. On the Mac side, we are planning a 6.5 release in the next couple months. Most of the changes in this release will center around 1Password Teams/Families/Individuals (the subscription option). Along with bug fixes that likely impact both. We are likely nearing the end of the road on version 6 after that.
With the $5/mo you can technically do two things...
1. You can use the hosted solution
2. You can create local vaults (like the standalone version does) and sync those using Dropbox, iCloud or Wifi (to mobile devices)
So, with the subscription option, you get both. Whether you use the hosted part of it or not is up to you. However, if the subscription goes into frozen state (unpaid) the app will go into Trial mode, which limits you unless you re-subscribe or purchase a standalone license.
I currently use both local vaults and the vaults for my work Team and Family account. Mostly the local vaults are for testing purposes but it all works fine with a subscription.
I put my elderly parents onto 1Password and they "got" it.
The hardest part of the migration for my parents were 1) demystifying the spaghetti mishmash my Dad had in place to manage his passwords, 2) getting Dropbox set up correctly between Mom & Dad for vault sharing, 3) training my Mom how to use, and 4) educating Data on how to manage website edge cases.
I would hope that 1PW has a LP migration tool, but if they don't, Dad was able to clean up his historical garbage one by one. The password capturing process in 1PW is good enough that this worked nearly seemlessly.
Finally, I've had nothing but positive results from posting questions in the 1PW forum.
How easy is it to migrate from Laspass to 1Password? I've had the worst experience with their tech support (reported 2 bugs that have both been scrapped as WONT FIX) and really don't want to support them as a premium subscriber anymore.
Disclaimer: I work for AgileBits, makers of 1Password
Yea, we hear you there. I (and others on the team) wish we could make this happen, but priorities are a tough one. Linux in general didn't fit all that great in our standalone license model before, along with being closed source. Now with the subscription option for individuals (new today), families and teams we have made the payment side a little less of a concern but we still have the closed source nature of things making Linux a harder target to hit.
We're probably in a better position now than before though. Every time I asked a Linux user who wasn't asking for this they said they had no interest in paying for closed source software. I wanted all the positive response I could get to show to the decision makers but I fell short in getting it.
This is all to say it's simply a complicated situation. It has to either make money to pay for its development, or the others have to offset it enough that it's a win for us so we can keep the lights on.
Hope that helps a little anyway. I know it's not the answer you wanted but I hate leaving people like yourself wondering why it feels like we aren't listening.
Is there a feature comparrison or reasoning you may have about why 1password may be better than Keepass? I have been using Keepass as I use Linux, Windows, and Phone for accessing my passwords. I am wondering if 1password has some neat helpful features that Keepass doesn't. I am considering switching to a new password manager.
We don't generally do feature comparisons. So many products operate under different sets of requirements that comparison charts can be very easily rigged to make one thing look significantly better than the other.
I can tell you one thing that is indisputably better about 1Password though.
Support.
Quite literally. We have a team of over 30 customer support personnel (in addition to myself and other developers who pitch in for a part of our day). We're here to help if you run into problems, encounter a bug, have feature requests, or generally just want questions answered about how we do things or why something is done the way it's done.
Keepass, as noble as it is to have an open source and free product, is run and improved by volunteers. I realize that not many people on hacker news really care that much about support since we're all typically very capable people, but as someone who has been with AgileBits for nearly 5 years now and seen a whole lot of the weird edge cases that can exist because some webpage is doing something incredibly weird or some particular computer setup is causing problems. It can be really helpful to know that there are people who can look into these things for you instead of having to know it yourself.
1Password does have a 30 day trial (both for our standalone product and for our individual/family/team subscriptions). You can try it yourself and see how it works for you. And as always, if you have questions during this time you're welcome to get in touch (support at agilebits.com, mention my name if you want and it'll notify me) and we'll help you get things setup. We think the product speaks for itself and we're happy to fill in any gaps if you need more :)
Out of the year I have been using Keepass I have never had a time where something was wrong that I would need support for.
I am actually not sure what I would need support for either, it seems pretty basic. I am simply storing passwords. It doesn't seem too complicated. And maybe this is because I am a tech person, so maybe I am looking for the more technical reasons why the software may be better rather than how the support excels. Because if keepass had a problem I know ways to get support anyway, either via a Stackexchange site or IRC. So I am definitely a bias group.
However I do not care if the software is open source or not. I know some people do care about that, but the people I talk to do not. People in my age group seem less concerned about open source or closed source.
I'm more curious if there are some kind of features in the product itself that make it better than keepass? I do not have a family so the family cloud version of 1password is not useful, though I would not be opposed to a cloud version of 1password for an individual. I currently store my keepass in dropbox and have that synced to all the devices I use.
An example I like to give for why 1Password Families has helped me is this:
I work remotely for my job. I do travel several times a year as a result and when I'm gone I have other family members watch my house. Before 1Password Families I had to find a way to easily get my wifi password, my garage door code, and various other instructions and information to whoever was watching my house.
With 1Password Families I simply create a vault in my Family, add my items to it and invite the person who will be watching my house as a guest (or in my most recent case, granted my brother access to the vault).
In the first case, the person simply signed up, installed 1Password and they had access to the data. In the second case, my brother simply unlocked 1Password and the vault was there.
When I get back home, I simply remove access and those things disappear from their devices. None of these are so important that I have to change them, but, that's another step as well if necessary.
But that is how easy it is to share and use vaults in 1Password Families (and Teams).
I also love that using this I can add family members, like my parents, and it handles all the syncing for them so I don't have to micro manage it with backups and other stuff. It's a far more seamless experience. And since I hold the keys to the family kingdom, I can also reset their master password for them if they forget it.
Now, you might think you have no use for this, and that's fine, but it's an example of how someone who doesn't have an immediate family (I'm single, and childless) was able to use 1Password Families in a way that wasn't obvious when I first set out to use it for myself.
In terms of features that differentiate us from Keepass, I have never used Keepass so I am not able to speak to what we do differently. I'm sure there are things each of us do better though.
There is a trial version of 1Password, so, you could use it and see how it stacks up for yourself. I'd be very curious what you find better or worse so I can pass that feedback along to our team. Completely optional of course.
Coincidentally, a bunch of Dropboxers are working on a version of 1Password for Linux written in Rust (it's Dropbox's "Hack Week" right now). Hopefully we can open source it soon. Looking good so far!
If you have any questions that we might be able to answer, please shoot me an email. kyle at agilebits.com, or support at agilebits.com. I work on our Mac/iOS teams and security teams. I can probably answer most of your questions and at least get them in front of people who can answer them.
I really hope you're not making this work with AgileKeychain, we've put that one out to pasture. :)
And also correct on the mini to extension protocol, there is no public documentation for that, primarily due to that being something we really need to be able to change as necessary.
We are really curious to see what you've come up with though :) So please keep me in the loop if possible!
I have been using 1Password since version 3 and highly recommend it. I personally am quite happy with the iOS support, synchronization, and mobile Safari extension.
If you're using a *nix system: https://www.passwordstore.org/ I switched over from LastPass a few months ago. It uses gpg for encryption and supports git for password syncing between systems. Pretty simple to set up and use. There are quite a few third party apps for it already (both desktop and mobile)
`pass` is based on well-established cryptography implementations: GnuPG. GnuPG is recommended by many security experts and used widely by journalists dealing with sensitive disclosures, e.g. the edward snowden documents.
It also doesn't try to NIH some complicated database format or syncing technology but instead uses well-established software (git, plain directory structure and gpg-encrypted text files) which makes it robust, flexible and future-proof, and also responsive to changes in cryptography as it benefits from upstream GnuPG updates. You can use any PGP key structure you want, or even hardware PGP devices like the YubiKey.
KeePass on the other hand seems to be based on mostly homegrown techniques written by people with no or limited understanding of cryptography. (see e.g. [0]) That said, I don't know how much KeePassX continues this trend - but it's based on the same file format so it presumably has to reimplement at least some of KeePass's homegrown crypto.
I don't know how much more convincing you need, but personally I wouldn't even dare consider using anything other than `pass`.
I tried LastPass, but didn't trust them, so I found https://www.passwordstore.org/ some year ago. I can't emphasize enough how good it is, mainly because it is so dead simple and transparent in how it works, and also because it has great bash integration, and uses git which makes it easy to sync between your machines. There is also a firefox plugin that integrates with it, but I don't really see that you need it: it is so easy to use at a prompt.
Don't use anything that runs in the DMZ (browser), if you care about your secrets.
I use keepassx, which requires manual search, copy, paste but it can store its vault on a cloud drive, mobile etc. and can have a key file or password.
Autotype is a bit risky because it assumes you've got the correct window/element focused. All it takes to expose your passwords is for a pop-up (e.g. instant message) to appear at the right moment.
Even if you don't hit the enter key/submit the form it is still possible for that incorrect window/app to grab your keystrokes.
My team and I have been using 1Password Teams (https://1password.com/teams/) for this. They also have a Families service if for some reason you want to do the same thing with family and friends.
I don't know about best practise but it integrates closely with Git. I store the encrypted passwords in a remote git repository. That means if someone else had the same GPG key and the password for that key, they could simply clone the repo and obtain the passwords. Equally they could add passwords and push them to the repo.
So that seems like a reasonable way for people to share them. However, I only use it for myself so I may not have thought of all the gotchas.
I just read the whitepaper (I am a long time Dashlane user) and they have a section on security of their javascript/browser extensions. They say that their extensions all use c++ so execute entirely outside of the javascript context. This would not have prevented the Lastpass exploit since all that was required as a malformed URL, but it is nice to see that Dashlane is thinking about this stuff. Also, had Lastpass not used js this exploit would've been harder to find (though not impossible).
Hello Julsimon, this is Simon from Dashlane's Support team. Thank you for your feedback. We have indeed ran multiple checks on our end and can confirm that we are not vulnerable to this type of issue. The code used for our auto-fill functions is shared on all our platforms and has been audited multiple times.
I found this alternative when LastPass was acquired by log me once. I was not happy with this. This app doesn't have hacking or vulnerability history like LastPass.
Speaking as an end user- seeing that they provide no incentive to 'hackers' to help them instead of using this information otherwise, I'd say I'm inclined to not trust them.
Normally I like bike shedding about bug bounty payouts just about as much as complaints about paywalls. If you are going to go poking around someone's code for fun or profit, the terms of the bounty program are readily available [1] so you can't complain after the fact for earning the maximum payout. LastPass isn't Facebook, and they never claimed they would pay more than $1,000 even for a full compromise or RCE.
On the other hand, using regexp to parse the URL when it's such an obviously security critical code path... just, why?!
The concern with the low payout is that it's supposed to be a way to compensate white hat hackers and dissuaded them from going to the black market with security problems like this. Given the business that LastPass is in wouldn't you agree that it's extremely crucial they make sure white hat hackers are aptly compensated for serious problems they find? In fact I'd think it'd be reasonable for them to pay more than Facebook for certain classes of bugs(like this one). After all all your passwords are more valuable than your Facebook account.
There are many people capable of finding this specific bug and reporting it who might be motivated to take a look by a bug bounty, but who would never even consider trying to sell an exploit on the black market. I agree there is one cohort where you are trying to offer them an alternative to illegally monetizing their exploits. Then there is another cohort who you are just trying to encourage them to spend some time with your code versus someone else's. I could only guess at the relative sizes of the two groups, but the optimist in me thinks bug bounties are less about the former than the latter.
As we can see from avlidienbrunn2's response [1] sometimes it's not about the money. It's just fulfilling a natural curiosity about a product, maybe getting your killer write-up of a shocking bug to hit the top of the HN frontpage, etc. So in this case perhaps the bounty program is as much about establishing a legal structure for a whitehat to operate under than to fairly compensate ad hoc pen-testers. I wish they paid 10x or more for this bug. But I'm glad at least pen-testers can report these bugs without [as much] fear of reprisal.
I agree with the cohort theory, but to me it's not so much about the risk of someone selling an exploit on the black market, all though it's still a risk. To me it's more about how it reflects on a company where security is key to their product. Low bounties kinda gives of a vibe of not caring about the security of their product and maintaining it.
Personally I lost a lot of confidence in them when they got acquired and switched to 1Password, paying very low bounties for critical security flaws further hurts my confidence in them.
Most companies, including companies far more security-sensitive than LogMeIn, pay no bug bounties at all. Meanwhile, the companies that pay the largest bounties are themselves routinely harangued online for underbidding the black market --- despite the fact that outbidding crime is in no way the purpose of a bug bounty.
From my vantage point, the logical conclusion to the comment you just wrote is that companies should avoid offering bug bounties. They just attract negative attention.
(I won't use LastPass, and have recommended 1Password --- but Tavis Ormandy is looking at 1Password right now, and I'm guessing they're going to end up disappointing HN too.)
It's true that not all companies pay bug bounties and you might very well be right that paying them, especially if they are much lower than other companies that operate bug bounties, might have a worse affect on public opinion then not having bug bounties at all. To me it's still concerning that Facebook pays 10x more for problems that are less severe and it does still make LastPass look like they don't care as much in comparison.
If this was a thread about a Facebook vulnerability, the exact same things would be said about Facebook. To verify for yourself, use the search box at the bottom of the page to find a thread about a Facebook bounty.
Wouldn't a true white hat hacker report the bug no matter what the bounty? Therefor, the bounty is in place to encourage black-hat hackers to report the bug instead of trying to profit from exploiting it. But I do agree that it is in a security company's best interest to offer high dollar sums for reporting crucial bugs. I am just arguing semantics :-)
It isn't a choice between "bother to submit or not", it's a case of a white-hat might be encouraged to look into this product rather than another product because of the bounty.
So the end effect is more bugs found by "white hats" rather than "black hats" because the bounty has focused the "white hat" efforts on your program. (Or encouraged them to look at all.)
I'm likely to poke around a site with a bug bounty even with small sums just because it hints at a more formal process and also likely means they have a sensible policy about not going after testers.
Bug bounties are as much about signalling than encouraging "black hats" to suddenly turn to the light side.
This is a non-sequitur response to my comment, whose whole purpose is to point out that a bug bounty is not a bid in an auction against organized crime.
You wish it was a non sequitur when it is completely relevant
We can agree to disagree because the perspective really wasn't for you, it was for everyone else reading that will share a sentiment they've felt but never articulated
In practice, in many cases, bug bounties are de facto a bid in an auction against organized crime. It doesn't need to be 1-to-1 equivalent bid, and it's not for all sources of found bugs, but the intent and the effect is definitely there.
No, they are virtually never a bid against organized crime.
There are two kinds of vulnerabilities in the world:
The kind organized criminals will pay tens of thousands of dollars for, and the kind they, like any Internet rando, will pay $50 for lulz.
If you think this dumb regex bug is worth the same to organized criminals as a Chrome sandbox escape or drive-by reliable Flash RCE... well, people think that about a lot of bugs, I guess.
This LastPass bug is terrible. I was already inclined to warn friends against using it (but my other friends have beat me to that punch many times before). The bug looks terrible for LastPass and its mere existence is damaging to that project.
But that doesn't mean the bug has significant monetary value. As someone else here cleverly put it on the last dumb bug bounty thread: you can smash a car with a sledgehammer, but that doesn't make the sledgehammer worth the value of the car.
No, but it makes sledgehammer-prevention worth something greater than zero and something less than the cost of sledgehammer repairs.
Bug bounty programs, presumably, prevent unsavory exploits at some point in the future. Having this responsibly disclosed was damaging still, but cost LastPass less money than having it exploited later.
I'm not sure where that falls on your "significance" scale.
I can think of few vulnerabilities with more monetary value than an arbitrary exploit of a password manager in broad use by a class of people who have access to huge numbers of private systems.
I think it's a bit of bucket A and bit of bucket B. Still even if one accept the definition you put forth the argument that having such low bounties makes LastPass look bad/like they're not caring is still valid.
No, it is not at all "bucket A" and "bucket B", and suggesting otherwise is a grave insult to hundreds of researchers who would never dream of attempting (and, of course, inevitably failing) to "sell bugs to the black market". Finding interesting vulnerabilities in software makes you clever and talented, not sociopathic.
> and suggesting otherwise is a grave insult to hundreds of researchers who would never dream of attempting (and, of course, inevitably failing) to "sell bugs to the black market".
No, suggesting otherwise is saying that a bounty program with high enough rewards can reach both legitimate security researchers and sketchy folks. This is in no way a slight on the first group.
So the people on this thread saying that this particular researcher didn't get paid enough to "do the right thing" just mean that this person seems a little sketchy?
Clearly not - merely that this bug could just as easily have been discovered by someone 'a little sketchy' and $1000 wouldn't be a big enough reward to skip setting up a watering hole or two for lulz.
Let's assume that there is a spectrum of honesty (say, from 1-10) and the pool of people capable of discovering vulnerabilities in your product includes people from the entire range.
If you're a 10 you will disclose responsibly regardless of a bounty, and if you're a 1 you will disclose to the highest bidder. The rest will weight profit, ethics, and risk in some ratio depending on where they fall on the scale and decide to act based on that calculation.
The company has to price their bounty on a few factors: how much they can afford to pay, how much a bug is worth to them (eg damage to their reputation, fines in the event of a vulnerability), and how important it is and to have researchers looking at their product instead of another product.
I agree with you that companies should not be required to pay people to prevent them from launching criminal conspiracies. But this is not a perfect world and people are not so black and white in their actions and motivations. There is no point trying to optimize your bounty program for the 1's or the 10's. Therefore, when optimizing for the rest it makes sense to pay as much as possible within the constraints I mentioned (in the previous paragraph) in order to tip the scales in your favor for the largest part of the spectrum possible. Right now the tech community knows about this problem with LastPass. If this exploit had made it to the wild things would've been much worse for them from a PR perspective.
I am hoping that the $1000 cap on the bounty program came from careful consideration of these factors, but my gut tells me it was a number handed down from management.
The point is to get more tens to even look at the code, not encourage people that have already found vulnerabilities to share them. I also think you vastly overestimate the percentage of criminals.
I mostly agree, but I would say that if the amount of a bounty affects your decision on whether to responsibly disclose it or sell to the highest black-market bidder, then you are at the very least a grey hat.
"On the other hand, using regexp to parse the URL when it's such an obviously security critical code path... just, why?!"
Why not? URIs are at least able to be tokenized perfectly well by a regular expression. You have to do it right, but there's little guarantee that your non-regexp code will do it right either. I glanced at that regexp and immediately recognized several potential problems with it... will I be able to do that with your non-regexp code?
To concretize the "several potential problems": 1. You generally don't want to parse arbitrary protocols, you should do something like (http|https|file) or whatever set of protocols you are ready to receive. Usually you're better off treating anything else as "not a URL", but consult your local security context for details. 2. Failing that, you want at the very least .⁎? to stop matching at the first :, or if your engine doesn't have that, the protocol ought to be matched with something much tighter like [a-z]+. And I do mean + and not ⁎, because you probably don't mean to support an empty protocol before the colon. (You may mean to permit URLs with no protocol, but that's (.⁎?:)? .) 3. Domains should be parsed more tightly than "not a slash". 4. Also, I have no idea what the @ was doing there. Perhaps it was trying to be $; URL parsing should always end with the "end of string" matcher to avoid problems similar to this. It should also start with the start-of-string matcher, which this one doesn't, for similar reasons. 5. Bonus critique, anything using regular expressions to URL-encode or decode is very suspicious; strongly prefer built-in functions that do this.
I literally saw all this faster than I could type it; does your non-regular-expression based code have this property?
Regular expressions aren't bad. They're hard to write properly, but still probably easier to write properly than anything else. It turns out the underlying problem is fundamentally hard.
(Had to use an alternate asterisk to get the RE expressions correct with HN trying to format it.)
which seemed to work well (although it was a bit slower, I probably didn't know about exponential backtracking at the time and that could probably be revisited). It won't gather multiple name/value pairs though, but it will cut out and name basically every other part of the URL.
What do all these have in common? They all demonstrate that it is hard to write a regex that parses URLs.
Regex's hide programming mistakes because they not only become harder for humans to parse as they get more complicated, but also there isn't simple programming code to handle potential security vulnerabilities in-line with the code. It also hides the [at least] two considerations of secure programming: designing a secure function, and handling the function securely.
Regular expressions describe finite state machines and in programming there's nothing simpler than finite state machines / finite automatons. Your handling of vulnerabilities inline is anything but simple. This is CS 101.
I can't even parse that. First sentence is false. Second sentence wouldn't follow from it if it were true, but then a false sentence can imply anything. And I've literally taken Security 101 in college.
You might also want to check the definition of "simple". Probably doesn't mean what you think it means.
It is hard to write code that parses URLs, period.
You can't look at regexs in isolation, see that a task is hard, then declare them unfit. You have to consider them as one of the many choices and analyze the cost/benefits of the whole suite of options.
I guarantee you that anyone who has said "Oh, gosh, this is hard, I'll just start using indexOf and substring operations" has written code that is just as broken, only in ways much harder to tell.
Which is probably why everyone here thinks it's better to not use regex. You didn't write better code... you wrote code that hid its brokenness better. That's not a good thing!
Again, my real point here is not "regexes are awesome in every way"... my point is that I literally glanced at that code and saw several ways in which it was wrong. Does your alternative have that property?
Also, some of the difficulties of regexes are accidental, not essential. Take something like the recent Perl 6 efforts for parsing and you're far better off in every way using that stuff than trying to bash together string-manipulation-based parsing, or whatever other alternatives you may be thinking of. The Perl 6 constructs will be more readable and more maintainable. (Perl 6 is crazy in a lot of ways but the parsing support is best-of-breed.)
And the problem is probably more accurately stated as "be suspicious of any function implementing encoding or decoding" rather than focusing on the regex part. Use the correct standard function. Don't bash something together yourself. They're actually pretty easy functions to write if you know what you're doing, but it's even easier to use some tested already-existing function. In fact, it's so easy that the fact that you see someone bashing together a URL encoding or decoding function almost certainly proves that they don't know what they are doing, which in turn means the URL encoding or decoding function was written by someone who doesn't know what they are doing. Unsurprisingly, these are, well, to quote myself, "suspicious".
Yes, that logic applies to URL parsing as well! Unfortunately, browsers make URL parsing extra hard, which is really stupid, so you end up with more crap in Javascript than anywhere else. Even then you ought to prefer someone else's tested solution over just smashing out a regular expression; however, it is not a knock on the tested solution if it is a regular expression-based solution.
Let's do a little calculation to see if the payout is worthwhile.
Using something illegally means you run the risk of going to prison. Let's say there's a 1% chance you get caught, the prison sentence is 10 years, and the evil hackers will pay you $20,000 for your bug. Let's also say that you're a mid-career software engineer in the US, and over the next 10 years you expect to make $2M (after taxes).
This means your expected outcome over 10 years is $20,000 + (0.99 * $2M) = $1.98M. With Lastpass's bounty you end up with $2.001M.
With these assumptions, you should be paying Lastpass to find bugs in their software! Of course, if you're not in the US, you probably make a more reasonable salary (read: less), taxes are higher, and the risk of getting caught is lower.
They authorize you to pry into their systems if, and only if, you report security bugs back to them. If you don't, they don't authorize you to pry into their systems, and it's illegal.
There is also the reputation boost that the researcher receives for discovering this exploit and disclosing it in a responsible manner. The value of that is incalculable.
Now let's bring that salary estimate back down from outer space. $200,000 per year TAKE HOME, is not realistic, except for the very top percent of developers. And I'm talking the very top.
>If so, I am a little taken back by LastPass only offering $1,000 to the researcher that found and reported it for fixing.
I am a lot taken back by it. This wasn't a minor bug. I don't care if $1,000 was the published maximum payout under their bug bounty program - for something like this, the payout needs to be representative of the damage that would have been done to their reputation had this bug been discovered and exploited by bad actors. Given that reputation is everything in this space, any well-publicized incident using this would have effectively rendered the company dead within days.
Here's hoping they reconsider the award amount (though I'm certain they won't).
Hi, newbie sec researcher here. Just wanna ask, how do we actually ask for a bounty considering that sometimes the severity of the breach is BIG (this, Shell Access, etc).
I really don't wanna ask the companies for money but it just seem so... underwhelming for me. (3 out of 3 rather big companies just gave some thanks)
No matter what it is, you don't just give someone something they didn't ask for, and then expect money in return.
It would be like someone walking up to you on the street, handing you something they think is valuable, and then hoping that you'll want it and pay them for it.
The first thing you should do is check and see if they have an official bug bounty, if they don't then contact them and ask them if they had one.. say something like "because you saw some things on their site that concerned you, but wanted to know if it was worth the time exploring further" .. this is assuming you already found something. The goal of this is to get them to try and offer a bounty.
If they don't offer a bounty, then if you want to be responsible, you can just disclose their vulnerabilities to them, and accept whatever thanks you get.
If you're explicitly doing what you're doing to try and get some money out of it, then your time would be better spent focusing on companies that have well published bug bounties.
Something to consider is a mis-alignment of incentives.
When LastPass gets breached, they're not directly responsible for what an attacker does with the passwords.
When another site/service gets breached, they have to spend a lot of time making it right to the customer again (e.g. rolling back transactions, compensating for lost or stolen funds, etc.)
He could have basically killed LastPass, the company, if he didn't go white-hat. And caused all sorts of other mayhem that would also have been far more profitable for him.
It does seem like an extremely low bounty for a security bug that severe.
I mean, in a 100% libertarian world, this hole would have been put up for auction to the highest bidder and LastPass would have had to ensure they were the highest bidder in order to close up the hole and basically save their business.
I don't think of the bounty as a reward for choosing not to break the law. Staying out of jail is the reward for not breaking the law; the $1000 is just a token of appreciation for someone that could have otherwise not bothered to report the bug.
I've been using LastPass for about 3 years, and now I'm seriously thinking about all the times people told me about how storing passwords in someone else's cloud is bad.
I've been defending LastPass and recommending it to everyone till today. Now I'm thinking about how I might have to 'pay' for a software vulnerability in some private (read:unauditable by me) code. All the comments about offline, local backups make sense to me.
But the points I usually make are still valid, like:
1. I can go to any computer with chrome and get access to all my passwords, so don't have to carry my passwords with me everywhere.
2. Don't have to worry about storing passwords properly since lastpass is a good company and they know their stuff about protecting the customers' data.
3. Password capture. It might seem like a tiny feature, but I'm too lazy to remember opening an app and entering my credentials whenever I create an account or login into an old account.
4. Mobile login, although a paid feature, this really changes my life. If I don't trust a computer enough to login via chrome or something else, or want my secret notes, I just open up my phone.
But all the above features meaning nothing when it comes to the chance of compromising all my passwords (except bank info, of course)
I'd like to hear the thoughts of anyone else who uses lastpass and what they think.
I think you could do a lot worse than lastpass. You could also do better, by sacrificing some usability. On the extreme side, you could use a separate, offline device, just for password storage.
But I don't think it's worth getting excited about a single lastpass bug. Everything is vulnerable. There will be more of them. Chrome itself had 105 security issues, just this year (https://www.cvedetails.com/product/15031/Google-Chrome.html?...) - a few of them potentially leading to your passwords being exposed without any extensions.
Upgrade often, don't do stupid stuff, keep backups, and you'll be more secure than 99% of people. Evaluate your choices from there.
Well, that put it in perspective for me. I just googled the vulnerabilities in offline password managers like Keepass/X and 1Password. And oh man, I was pretty shocked to see even the offline ones could be broken into.
I think I just had a crisis of faith.
>you'll be more secure than 99% of people
Thanks. I guess since I don't store very sensitive info (financial, etc.), and the important services - Google, Github, Atlassian, AWS use 2FA. I guess I don't have to be paranoid.
I do not use LastPass exactly because of what you describe. I use a KeePass Password safe without autofill. I use other software to sync the file. It used to be Dropbox, later I was using BitTorrent Sync, but what tool sync shouldn't really matter. As I see it: the tool only gets to see and sync an encrypted file. You could even use a USB stick and not sync at all. Or only sync on LANs.
I love it how I get to decide who or what gets to see the encrypted file.
Now hopefully the Keepass audit will not reveal any issues in the encryption.
Not entirely, since you download the encryption code way more often (for example, when you open the "Lastpass Vault", which is just a website like any other). Parts of Lastpass are simply a website, not part of the browser extension, and as an avid Lastpass user in all honesty I don't know which parts.
This matters because even if it's client-side encryption, the encryption code just got downloaded when you opened the site so if the server or the network was compromised, you got compromised. [0]
With Keepass, the only time you run that risk is when you download Keepass.
[0] As far as I can tell, this is the core argument of tptacek's "javascript crypto considered harmful" rant (https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...). I'm not sure, because it's written worse than his most drunken HN comment, but I believe it is.
Ah, yes, I was assuming the website would be avoided. I didn't realize it was hard to distinguish (I don't personally use LastPass, I prefer Firefox Sync).
I'm pretty sure when using the Chrome extension, all the HTML/JS is downloaded locally once when installing the extension, as logging in via the extension brings you to a chrome-extension:// URL. When logging in via lastpass.com, of course, you will be redownloading the crypto code every time.
The post does point out that this would not work if multifactor authentication is on. I would never dream of using my LastPass account without that anyway.
Like with all decisions this is balancing risk/reward. The reward are all the points you have already expressed that I also love about LastPass. Currently I believe the risk is fairly minimal assuming you use 2 factor-authentication. Though I might turn off autofill now as an extra precaution.
I'd say some of the points could be easily covered by something like KeePass which, unlike cloud, doesn't have to depend on questionable security of third-party services.
For example. I use KeePass to store all my password. I keep my KeePass database in Google Drive, so any change to the file will be updated. because of that I can use KeePass on any machine that has access to Google Drive (I also keep executables for various systems in drive). Furthermore, there are number of free mobile applications for KeePass which can hook into GDrive and you can use KeePass on the phone too. And lastly - browser extensions which let you use your KeePass to automatically fill & save passwords (I don't use it, though).
Sure, KeePass requires a bit more of an effort compared to all-in-one solutions such as LastPass. That is the price you pay for not thinking about possible security breaches in the cloud.
It's not really very much more effort. I use KeeFox (Firefox) and Keepass2Android (you can guess). I love both tools, they've made password management trivial, and I used to be a die-hard "one password for everything is just so much more convenient" fan.
I keep the file in Dropbox, Keepass2Android automatically syncs it every time I open the database and merges any conflicts. It's pretty nifty, I've never had a problem.
Integrating with the browser is probably a bad idea, it shortens the exploit path from a webpage to your password store.
Using a standalone application and using the clipboard would require a malicious website to break out of the browser and then break into the password store process, which could in principle run under a different user and interact with the clipboard through some broker process.
> I've been using LastPass for about 3 years, and now I'm seriously thinking about all the times people told me about how storing passwords in someone else's cloud is bad.
This bug doesn't seem to have anything to do with the cloud.
FTA:
> The bug that allowed me to extract passwords was found in the autofill functionality.
I use Lastpass for work and can't stand it. I use 1Password for personal stuff (and some private work stuff now that I think of it) and highly recommend it. It's got a Chrome browser extension, mobile app, and like someone else mentioned below you can sync the encrypted db to a cloud service (iCloud, Dropbox, etc) so you can access it from all of your devices.
I don't mean to be the advice bird, but maybe you can point all the points you made to your superiors and make them re-evaluate their choice. If they're a huge enterprise, then I understand
I work for a company with 3 owners and approximately 40 people. It would be okay but we need the shared 'team' aspects of a password manager -- I could be mistaken but I don't think 1password can handle a team sharing logins. I'm sure there are other options out there.
> 1. I can go to any computer with chrome and get access to all my passwords, so don't have to carry my passwords with me everywhere.
Maybe a computer you can trust but I wouldn't say any computer. I consider the shared PC you'd find in a hotel business center to be the digital equivalent of a diseased hooker. I'd be impressed if it didn't have a key logger installed.
> 2. Don't have to worry about storing passwords properly since lastpass is a good company and they know their stuff about protecting the customers' data.
Not being OSS I don't think that can be proven. It boils down to "Trust us, we're smart".
> I'd like to hear the thoughts of anyone else who uses lastpass and what they think.
Trust noone and put your faith in OSS (KeepassX, pass, etc).
> Maybe a computer you can trust but I wouldn't say any computer. I consider the shared PC you'd find in a hotel business center to be the digital equivalent of a diseased hooker. I'd be impressed if it didn't have a key logger installed.
I think you'll be impressed in a lot of cases than. I would be surprised if more than 15% of shared PCs have keyloggers active on them.
Still doesn't mean i'm going to login to anything on them though.
Good point. Perhaps a modification can be made that is restricted to generally safe characters, then you can add your own stuff as the website demands. Which then leaves you to remember which stuff you need to add, on every site - so not that great.
Or there could be several modes and a database of websites that automatically picks a mode based on the website. Which leaves you remembering modes in the worst case scenario, or trying a few of them out.
I think an acceptable solution can be made by analysing the password requirements of the top N websites, then coming up with a good scheme that works on most, and an alternate scheme that works on the rest. One mistake is usually allowed everywhere.
I have never understood the password manager market honestly. To me it's very obvious that the CONCEPT of a "single point of failure" is a terrible idea. Putting faith in one or the other is just like humans backing politicians, they think they are backing something when really they just got manipulated into an opinion which they slowly defend more and more.
Don't use a password manager, remember your passwords, or reset them all the time. It's a conceptual vulnerability, and if you read hacker news you are better than this.
Are you saying that you remember a unique and sufficiently random password for every website/app/etc you use? If so, you've got a far better memory that me.
So do you use encryption on that combined version? If yes, how do you deal with different requirements (one website says symbols required and more than 8 characters, another says symbols forbidden and less than 8 characters). If no, what stops someone who finds one password from changing the service name part and trying it somewhere else?
No encryption or hashing, since that would require (easy-access to) an external tool and lacks control over length and characters. It's not possible to simply change the "name part" of one of my passwords since the general format looks something like: {password_base}{service_cipher}{username_cipher}{special_chars}.
Depending on the type of service, `password_base` changes. For example, HN uses a separate one from Gmail for Business. Likewise, `service_cipher` and `username_cipher` are simply that: truncated ciphers of the service name and username. Lastly, `special_chars` is used for pesky sites that want special characters outside the range provided by my password base.
I'd like to think my system is very difficult for someone to crack without gaining access to a large number of passwords. The only limitation is that a few sites have limits on password length(!) which requires using a shorter base or even truncating the password entirely.
Its been recommended (at least as long as I've been using Lastpass, so a few years) that you keep autofill disabled, for exactly the reason mentioned in the article.
"Also, this would not work if multi factor authentication was on, so you should probably enable that as well."
If you have something as important as a password manager (ie something that holds the keys to ... everything), then MFA is a must. If you use LastPass without MFA, then you're probably asking for trouble.
One should really consider using open source tools for such things. The good thing is that those are battle-tested real well and are, usually, more secure than the commercial offerings.
An example is Vault [0].
Encryptr [1] is another alternative: it claims that "all of your data will be saved in encrypted format in our Zero Knowledge [2] cloud".
Please correct me if I'm wrong, but lastpass uses the same 'zero-knowledge' method that spideroak uses, other than spider oak uses that term everywhere including their cloud backup offering.
Zero knowledge is merely the fact that spider oak only holds encrypted backups of your files and it has no way of seeing them. LastPass tells us the same thing.
Could someone explain me better the posted code that was vulnerable? I don't understand it. What's the returned value?, what is URL and url?, why the extension is expecting there must be a @ inside the url?
Very simply, I have a password stored for "login.example.com". LastPass knows that companies like to change URLs - so next week it might be "userlogin.example.com" or "secure.example.com/login" or "www2.uk.vpn1.example.com" etc.
Essentially, LastPass made the mistake of writing code which said "If you see `example.com` anywhere in the URL - assume that you're on the right site.
LastPass will allow you to automatically fill in the username and password as soon as you visit a site (I think this is an optional feature).
An attacker convinces you to visit "badsite.wtf/@example.com/". LastPass sees the "example.com" and autofills the password field. The site has some JavaScript to detect the filled in details - and steals them.
I don't quite follow. The author says that by entering the URL "http://avlidienbrunn.se/@twitter.com/@hehe.php", the extension is fooled into autofilling as if the browser was on twitter.com.
An attacker could fool the extension to autofill a form on a domain they control with credentials from another domain and send the credentials to their server.
A bug that tricks the secure password management tool into revealing your Twitter password to a website that is not Twitter! That's a pretty major security vulnerability due to a bug in URL parsing.
Yes, but some JavaScript can detect that the text field has been filled, and then send the information back to the attacker's server. An (innocent) example of this is when you type something into Google's search field, and you already see suggestions, even though you haven't clicked anywhere or hit Enter yet.
Great catch and everyone should know there is an easy way to parse URLs in JS. Just create an anchor element and let the browser parse it for you. Like so:
While that might be an "easy way" - it isn't a secure way in this case.
Since malicious attackers have complete control over the page you're seeing - they can simply replace document.createElement with their own function.
And instead of returning a DOM object, they can return an object that returns whatever they want in .hostname
At least in Chrome, I'm imagining the raw url would be sent to a background process that is sandboxed from the webpage and would then do the createElement stuff.
Disclosure: I work for AgileBits, makers of 1Password.
For desktop browser extensions that are properly using the frameworks, the extension's Javascript runs in its own execution context so the page cannot redefine variables. This protected 1Password when we discovered that a certain page had redefined the global JSON object, which provides parse and stringify functions among other things, to be the number 3, i.e. a numeric constant called JSON. :'D
We really try not to call it "Classic" or anything like that. It's standalone, you're in charge of upgrades, syncing and backups and stuff like that. It's also not designed for sharing (at least to the degree of the Family and Team solutions).
That said, we don't have any immediate plans to remove the standalone products. However, if a vast majority of our users switch to 1Password Family or 1Password Teams (and as of today, an Individual plan!) then it doesn't make a ton of sense to keep the standalone product around. So, it's probably one of those speak with your wallet kind of scenarios.
I'll certainly pass your feedback along, it sounds like you'd like to keep it around.
I also very very very strongly do not want any hosted service requirement for using 1password. I am very proud user of 1P but a hosted requirement would kill it for me. No matter how much you (the generic 'you') tell me you're super secure, nothing will be as secure as owning my own data and using local Wi-Fi sync to put it on my phone.
While I understand your concern, and to some extent, sure, you're right that owning your own data does reduce certain attack vectors it's also a trade off that a vast majority of people don't have to worry about either.
But the real important thing to consider is whether the protection you would get from a hosted solution so above and beyond overkill that it matters?
If you're curious why I feel that way, we have written up a white paper on how 1Password Teams (and therefore Families and now Individuals) stores and secures your data.
We designed 1Password so that we cannot know anything about your data. We also designed it knowing full well that our servers would be a target. So, we designed it in such a way that if a malicious person were to acquire your data there's more or less nothing they can do to acquire the decrypted data.
What we settled on is having two secrets. Both of which are not known by us. The first is your Master Password, something that you're likely well aware of having used 1Password already. The second part is an Account Key, which is a random 128-bit key generated locally. These two things are never given to us and should never be shared. They are both used for the cryptographic functions in 1Password. Without them both, you can't see the decrypted data.
This is unique in that it actually protects weak master passwords. That's the big deal to worry about if our database of user data is compromised. The first attack is to start running password cracking tools against it to try to find the weak passwords. Except in this case, there are no weak passwords because even if your master password is "a" the attacker still needs your Account Key, which looks something like this:
A3-Z4JZ6V-P9BALK-S6J69-FAXCN-LTDY8-T3QHJ
So, now a password cracker is going to have to guess all those combinations of weak passwords against something much much stronger as well. I wish them luck because the math more or less makes this impossible if a user uses a strong master password as well.
There's some math in the white paper if you're curious about more.
Knowing how it works and how extremely unlikely it is that I am such a target that someone is going to literally spend millions upon millions of dollars trying to crack my account (and still likely get nowhere)... I'm small fish, it just isn't worth it to even try.
Either way, for the sake of learning (I love learning, so I always assume others do as well), I would recommend reading the white paper, if not only to gain some new knowledge that you may not have been exposed to previously. If you have, awesome!
Seconding this. I generally dislike hosted subscription offerings, especially for a password manager, and even more especially for one that I've already purchased four different licenses to (Mac, Windows, iOS, Android).
All 3 apps are open-source. This is important because open-source will not die for as long as there is demand and more importantly, you own it.
No, I'm NOT against proprietary software, as I said, I gladly paid a premium for 1Password. However their Windows client is basically unmaintained, their new "modern Windows" app is still alpha and doesn't work with Wine and of course, they have no Linux support. Most aggravating is that they are clearly switching to a subscription model, with all of their development effort going towards it lately. No more Everywhere interface for OpVault, no new sync options other than Dropbox and iCloud, etc. In other words I'm tired of bait and switch models and one is in progress here.
Please do consider keeping the standalone apps. Not having my passwords stored on someone else's server (encrypted or not) is why I'm a 1Password user (and likely buying an upgrade license this month to load it on my other windows box). Similarly why I've bought and upgraded Arq to store backups on storage I control.
Out of curiosity, does this apply only to Chrome's extension framework, or to Firefox's and Safari's as well?
Context: I'm a new 1Password user who is contemplating use of the extensions for those latter two browsers, and while it seems probable their extension frameworks offer the level of security you describe, I'd like to be certain before pulling the trigger. Thanks!
Yes, all 3 of the major browsers (and derivatives of them) offer the same support for a sandboxed execution environment. You can safely use any of them if that's a requirement you have :)
No, that is not possible. Extensions in Chrome run in a different execution context than the website. The website's document.creatElement is different from the extension's.
If the website could override extension functions, attacks would already be possible by overriding Regex functions.
Good point, but that's assuming you're running in the context of the popup and not in the context of a content script.
In the popup's script, you are using a new DOM. But in a content script - you're using the same DOM as the client, which can override createElement
(and any other function as well).
While content scripts (in the extension world, meaning scripts running in the context of a content page) shares the DOM with the untrusted page, it does not share the JavaScript wrapper layer around that DOM. This is extra confusing because the global object is a (JavaScript wrapper around a) DOM object.
The untrusted script can override its own view of createElement, but not the extension's view.
The page could only see a mutation event and get a reference to the element if the element was attached to the document. If the extension never attaches the anchor element to the document, then the page's code can't get to it.
> Content scripts execute in a special environment called an isolated world. They have access to the DOM of the page they are injected into, but not to any JavaScript variables or functions created by the page. ... The same is true in reverse
I don't know about this specific point, but you might want to take a look at the greasemonkey security pitfalls page [0]. There's been a lot of effort put into how all of these parts work together to make sure that malicious Javascript on the page can't interfere with what the plugin or userscript is trying to do.
Chrome extensions' content scripts are under stronger isolation from the page than greasemonkey scripts are (or were? -- I'm not sure if greasemonkey has changed since). Chrome extensions run in a separate "isolated world" from the page. They never share javascript objects directly. (They do share the DOM, but the isolated world gets its own separate Javascript wrappers around the DOM.) It's not possible to leak a function from the extension to the page, etc.
I think the point is that this would run in a document belonging to the LastPass extension -- not that it would run in javascript injected into the target site.
The same attack you describe could be applied to basically any javascript you cared to write (say, String.prototype.length). The safest approach is to treat the output of injected javascript as untrusted third-party input to your extension code and work from there.
Disclosure: I work for AgileBits, makers of 1Password.
For browser extensions, the URL constructor would be even easier: https://developer.mozilla.org/en-US/docs/Web/API/URL/URL (Yes, I know it says that IE doesn't support it, but IE doesn't have a proper extensions framework, so it's irrelevant to this topic.)
What you are really "asking" is logically equivalent to this blaming statement:
"I see you are posting about LastPass' vulnerability, but you work for 1Password. Please confirm there exists a regex vulnerability in 1Password which is similar in nature to the one that occurred with LastPass."
Put this way, the insanity of the statement is obvious. In questions, it becomes less obvious to the majority of the population, which only serves to spread the insanity to others.
Don't feed the fear with dissonance.
Edit: It is NOT "reasonable" to ask questions with negation in them which assume blame in a piece of software which is, by a rather large assumption, a completely different code base. Reason is based on logic. This question was based on fear and uncertainty, and only serves to spread it further.
I see no need to read that into it. It's a reasonable question. Sounds like they just want to know if they, as a 1Password customer, could be affected. A little misguided, but a reasonable question.
While this is something I'm generally curious of, especially with regex vulnerabilities being such a hot topic in software right now. See, for example, the regex issue last week that caused Stack Overflow to go down [0]. That aside, my concern stems solely from being a 1Password customer.
Here's some context: I am a former LastPass user for many years and current (concerned) 1Password user wondering if I should be changing all of my passwords again.
My goal was to settle concern for myself and other 1Password users. That's why I wrote whether a similar vulnerability "does not affect 1Password" instead of "does". My apologies if this was unclear.
I've been using LastPass for years now, but I'm starting to explore other options.
For me, the biggest pain point is the interface. The automatic form filling rarely works as it should; I click the LastPass icon in the username field, select the site, and it only populates the username (even though there is an input with type="password" right below it).
I then have to:
1) Press ALT+W to bring up the LastPass site search
2) Type in the domain name
3) Find the correct entry, and then click "Show Password"
4) Use my mouse to highlight the password and copy it (there is no quick way to copy the password)
5) Close the tab, go back to the original site, put my cursor in the password field and paste it
And then I have to worry about what password I may or may not have lingering in my clipboard.
If anyone has a better workflow please let me know. I'm envious when I watch coworkers use 1Password to populate a form in two steps using hotkeys.
I use 1Password like that. I'm starting to explore other
options because I'd much rather pay for open source software. Dropbox and 1Password are the only proprietary software I really depend on... cause it's 2016 and everyone else got the memo, even Microsoft is changing.
What browser are you using? Lastpass usually autofills for me, and if it doesn't, there's a menu widget in both the password field and the plugin menu that goes right to the domain, and has a copy password to clipboard option.
Using Chrome on Windows, I can right-click anywhere in the browser window, select "LastPass", select "Copy Password", and click the domain/user. (There's usually only one listed, unless I have multiple accounts on the site.)
Then just click the password field and Ctrl-V, of course.
If you're concerned about the clipboard, get in the habit of typing Shift-LeftArrow Ctrl-C after entering the password, to quickly replace your clipboard with a single character.
> And then I have to worry about what password I may or may not have lingering in my clipboard.
I'm not sure how LastPass does it, but 1Password does clear the clipboard after a short period of time (configurable, I think 90 seconds by default). I use clipboard logging via Alfred, and can confirm that however they clear the clipboard works to keep them out of its log.
- This is the second serious security incident with them. Nobody's immune to bugs, but I haven't seen a similar history with AgileBits.
- LastPass has, IMHO, terrible UI/UX. Things don't work consistently, there are weird, unexpected pauses that look like malfunctions until something visible happens; it took me a comparatively long time to figure out how to map common actions to the gestures that perform them; and finally, this is way down the priority list, but I find it generally kind of ugly. I suspect some of these complaints are partially linked to the next point.
- Lastpass is more trouble than it is worth in Safari/Mac.
I've used 1Password personally since 2008-ish, and think I've had exactly one nontrivial problem with it in that time, which was my fault. (There was some upgrade-path weirdness with the iOS version several years ago, and I left a device unused long enough that it ended up with orphaned data I couldn't sync. I forget the details of what exactly happened.)
1Password Teams didn't exist when my company started using Lastpass, but I'm hoping to get switching onto the low-priority project list.
> ...I'm hoping to get switching onto the low-priority project list.
You should maybe try and get it on the high priority list. On August 1st the Teams pro plan will increase from $4/user/mo. (introductory price) to $12/user/mo. for new signups: https://1password.com/teams/pricing/
> - Lastpass is more trouble than it is worth in Safari/Mac.
Can't agree with this more. I've had so many issues with LastPass staying logged in one browser across sessions, even though the preferences are set to logout after short inactivity windows and on browser quit. LastPass seemed to lose its preferences like this multiple times, and it made me uncomfortable from a security perspective to not know for sure when my sessions would actually end.
Besides that it's mostly UX issues for me, similar to what you've described.
I also prefer 1Password's pronounceable random password generator vs LastPass's generator (obligatory xkcd https://xkcd.com/936/).
Another really cool trick it plays is that it enables Secure Input, as it should, but then never disables it. So it breaks 3rd party tools that expand shortcuts, automate UI actions, etc. like TextExpander, which I use a lot.
I've had this trouble in Chrome quite a bit too. For example, system level text expansions break in the Chrome omnibox. I think that's independent of LastPass, but I could be wrong.
I'm actually talking about sort of the reverse. Secure Input is a system-level thing; it disables input capture via the accessibility API (which things like TextExpander use), which effects everything on the machine. That is what you want; when typing a password, there is no good reason for other code to be reading what you (or LastPass) is typing. You just also want it to be turned back off when you're done.
But after the first use of the LastPass Safari extension, TextExpander (or KeyboardMaestro, or a bunch of other tools) won't work anywhere until a after reboot or some other method of disabling SI.
I was about to downvote after reading your edit, but part of me likes that attitude. That you're so passionate about your objection actually helped me arrive at the same conclusion. That and my own thought: Why would a developer come on here to suggest a fix if they weren't aware of this potential security flaw?
There are appropriate channels to ask questions like that and appropriate times to downvote. But, hey, I'm not here to offend the hivemind. Please have mercy ;)
I save downvotes for truly awful comments made in a blaming way. If a comment I've made is non-blaming, yet addresses the more uncomfortable bits of reality, I fully expect to be downvoted. In this case, within several minutes I was at -2, even when there was no "fuck yourselves" in the post. Interestingly enough, when I added it, there appeared to be more commenting occurring.
While I would agree that this place would be better off without judgment, and harsh judgment as I've shown here, the reality is that we all share this place equally with others who do not stop and consider their actions as affecting others thought processes in a negative way. I put this on here to illustrate that point in a non-obvious way, and in a way people CAN understand: anger. It's not the only way of course, but it does get the bug into people's brains quite well.
Interesting view on the matter, even if I don't quite agree with your prev comment (too tired now to argue why, sorry).
I very much agree that downvoting without comment (indeed except for the truly awful ones that would just draw needless noise because of it) is an anti-pattern. But I am occasionally guilty of it myself as well, partly because writing a reply to a not-quite-awful comment costs me a lot of time (even if it's a short cmt).
The greying-out of downvoted comments doesn't help with the perception of receiving a downvote without comment either (makes it feel more harsh, IMO). I'd prefer showing the counts again, actually.
It happens often enough that a comment gets downvoted initially, and then gets sympathy upvotes from people who don't find it bad enough to be voted down. It may help to wait a few more minutes.
Why not take a look at the code injected by 1Password's browser extension and find out for yourself whether it handles URLs safely? That shouldn't be hard to do, and it's a lot healthier for the community than discouraging devs to participate by taking their presence as an opportunity for drive-by pot shots.
I'm sorry, but I don't see how asking an employee of the company that makes the product that I use every day is "discouraging devs to participate by taking their presence as an opportunity for drive-by pot shots".
I think an official word holds more clout and is more valuable than any one person confirming for themselves in one version of one browser on one version of one OS.
I did speak rather harshly in my prior comment, and for that I apologize. Worse, I did a very poor job of expressing the concern that motivated me to respond. But I think it's still fair to ask whether your initial comment has value.
I understand that, as a user of 1Password's browser extension(s), you may well feel some concern that a similar vulnerability exists, and I don't think it's unreasonable to want reassurance on that score.
But I think your phrasing and framing of the question feels a lot more like a "gotcha" than anything else, and it's that feeling which motivated my prior comment - I'm not an AgileBits dev myself, but if I were, I'd feel strongly inclined to shy away from that question rather than trying to frame an answer that doesn't leave me open to a potentially hostile followup.
Fwiw, his question did not sound at all like that to me. Your reaction feels like unfair personal bias. Not trying to start a fight but you seem openminded enough to hear it so figured Id let you know
Not at all. But I would be interested to hear what sort of bias you saw in my prior comment. I mean, I don't think you're wrong, but beyond the downvotes, I only have my own perspective to go on here, and I'd appreciate the benefit of having yours as well.
Not the poster you replied to, but there were 2 types of bias I saw:
1: Defensiveness. It seemed more like an honest question than a pot shot. You seemed to read into it something like "Aha! How about your software fool!?!"
That said, if it were a reporter asking the question, then I would see it as a gotcha, because the use of the word confirm is used as a setup sometimes.
2: Tech bias. Not everyone on here is a Dev, and even though I know a fair bit about programming it would not be a trivial task to do what is simple for you regarding checking out code injections and what they do re a security standpoint. That would probably be a long afternoon of googling for me :)
Sure. I took the original question at face value: It was a user who was concerned and wanted reassurance. Imo, it's a big leap to read it instead as a setup for a hostile "gotcha" style followup. I mean, is it possible? Sure. But there's no evidence for that interpretation. And to take a stats view, the bayesian priors aren't there (ie, most people aren't conniving snakes). Given that, it seemed to me that you were bringing your own kind of evidence to the table -- perhaps a personal experience in which you'd been similarly setup and mistreated.
Update: Here's the response from earlier this morning:
> Thank you for taking the time to write to us here at AgileBits. The current version of the 1Password extension does not use regex to parse URLs for this exact reason. We don't autofill either, which also helps avoid issues like the one you mentioned.
Also, just because we're on Hacker News, it doesn't mean every reader is equipped to audit code for security vulnerabilities.
Presumably that's the job of a professional security developer that might reasonably be expected to have checked their own similar product for this vulnerability...
Fair. I would, though, expect someone whose HN profile identifies him as an experienced full-stack engineer to be up to the challenge of spotting something as basic as an extension injecting code into untrusted DOM and trusting the results that code gives back.
Not a dev on either product, but I use 1Password for my personal accounts, and a corporate LastPass for my work accounts. I do not believe that 1Password is as immediately vulnerable as LastPass.
LastPass (on Chrome) will auto-fill information on a detected site, which a malicious site can read immediately.
1Password (on Chromium nightly) requires me to hit the 1Password Mini button and select a site/account to log in with. If 1Password had a similar vulnerability, a malicious site as described would merely wind up showing me accounts for the wrong site in the dropdown. Clicking one could wind up submitting/leaking my credentials to the attacker, though.
It does have an "open and fill" feature which autofills, but only immediately after opening the site by URL first. (So the attacker's URL would have to be saved in 1Password along side your credentials.)
This is actually how I use 1Password most often. Global hotkey of cmd+opt+\, type a site name, hit enter: 1Password opens the site and logs in.
But that shouldn't be necessary here, if I understand the problem correctly. The code Lastpass was looking for was simply `document.location.hostname`.
Another regex bug what a surprise. Do not store whole password in LastPass. To mitigate this kind of attack I store only part of it on LastPass. The full password is <last_pass_generated_password> + <few_char_nonce_that_I_know_how to_generate_in_my_head> + <short_password_stored_in_my_head>
LastPass user here, thanks for getting this fixed. For any other bug/attack like this in future, I suggest we uncheck this option: "Automatically Fill Login Information" in preferences tab. Will this would have helped in case of this attack? Or information still would have been leaked?
There's also the issue of users being stuck on older versions of the addon.
Update: Looks like LastPass has made a blog regarding the exploit and have stated v3 of the addon is not affected [1]. Would be nice to have further clarification of the differences between v3 and v4 with regard to this.
I wonder if it would be possible to use window.history.replaceState to do this after the page loads - eg, not having to link the user directly to www.badsite.com/@twitter.com. A link to www.badsite.com by itself wouldn't even look remotely suspicious.
You could even use replaceState to change it back immediately.
441 comments
[ 5.1 ms ] story [ 293 ms ] threadUpdate: after a few answers to my badly thought through comment, I now feel enlightened. The attack scenario is a malicious web site which can gobble up my passwords. Thanks
1. Writes up that post.
2. Inserts an iframe in the post, which enumerates known sites. (hidden out of view with css tricks)
3. Instead of alerting on screen, sends the results back to their server.
4. Submits to HN.
So no, I don't think it will only give you your own passwords.
(to save a click: Tavis Ormandy: "Are people really using this lastpass thing? I took a quick look and can see a bunch of obvious critical problems. I'll send a report asap.")
> @taviso Are you looking at their binary? (I'm a former lastpass engineer)
> @ejcx_ Yes.
> @taviso Ahhh. I never touched it. Very neglected. There's a lot of stuff between message passing between extension and binary that is scary
https://twitter.com/ejcx_/status/758080992724738048
Verbal Expressions - It's an extremely good higher level interface to the underlying regular expressions tools, in MANY languages.
Including:
JavaScript - https://github.com/VerbalExpressions/JSVerbalExpressions
ActionScript 3 - https://github.com/VerbalExpressions/AS3VerbalExpressions
Clojure - https://github.com/VerbalExpressions/ClojureVerbalExpression...
C++ - https://github.com/VerbalExpressions/CppVerbalExpressions
C# - https://github.com/VerbalExpressions/CSharpVerbalExpressions
Dart - https://github.com/VerbalExpressions/DartVerbalExpressions
Elixir - https://github.com/VerbalExpressions/ElixirVerbalExpressions
Elm - https://github.com/VerbalExpressions/elm-verbal-expressions
Erlang - https://github.com/VerbalExpressions/ErlangVerbalExpressions
FreeBasic - https://github.com/VerbalExpressions/FreeBasicVerbalExpressi...
F# - https://github.com/VerbalExpressions/FSharpVerbalExpressions
Go - https://github.com/VerbalExpressions/GoVerbalExpressions
Groovy - https://github.com/VerbalExpressions/GroovyVerbalExpressions
Haskell - https://github.com/VerbalExpressions/HaskellVerbalExpression...
Haxe - https://github.com/VerbalExpressions/HaxeVerbalExpressions
Java - https://github.com/VerbalExpressions/JavaVerbalExpressions
Lua - https://github.com/VerbalExpressions/LuaVerbalExpressions
Objective C - https://github.com/VerbalExpressions/ObjectiveCVerbalExpress...
Perl - https://github.com/VerbalExpressions/PerlVerbalExpressions
PHP - obsurveyor ↗ You could have just linked to http://verbalexpressions.github.io instead of spamming all the repositories. Also, about half of them are out of date by 3 or more years. elktea ↗ The point being it's available for a wide range of languages techdragon ↗ Exactly... I probably could have posted less of them but in an era of TLDR it was easy enough to just post the list and let the uninterested scroll past and ignore it. That I have down votes for pointing out how practically no developers are without an option to guard against poorly written regular expressions, feels somewhat overkill. dpark ↗ I don't see how this would have prevented this problem. The issue was not that regular expressions were "too hard" for the lastpass team, but that URLs are hard to parse correctly. To put it another way, if you don't know how to parse a URL correctly, you'll probably write an incorrect parser no matter what parsing tool you use. That's why you generally shouldn't write parsers for URLs.
Where a regex must be used, there is a reference regex for parsing URL: https://tools.ietf.org/html/rfc3986#appendix-B
Edit: a permalink to demonstrate the above reference regex: https://regex101.com/r/yJ5nU4/1 -- would have prevented the LastPass bug.
The string "foo" correctly gets parsed as a path (group 5). However the string "foo;key:value" gets parsed as a "foo;key" scheme (group 1,2) and a "bar" path (group 5) by the regular expression, but as a path if you follow the grammar.
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
vs.
^(([^:\/?#]+):)?
:; are reserved characters, but they do not need to be encoded when they are a part of the path.
So yeah, don't use regular expressions for parsing.
How (and how often) are updates pushed to the client?
They're pushed via Chrome's extension store. Definitely at browser startup, but otherwise periodically every 5 hours (by default)
It stores your data locally, is suprisingly easy to use and relies on battle tested GPG.
From the website: "The community has even produced a cross-platform GUI client, an Android app, an iOS app, a Firefox plugin, a Windows client, a pretty Python QML app, a nice Go GUI app, an interactive console UI, Alfred integration (1) (2) (3), a dmenu script, OS X integration, git credential integration, and even an emacs package."
[1] https://www.passwordstore.org/
The lack of integration then with the rest of the OS is actually a security benefit.
https://www.schneier.com/blog/archives/2005/06/write_down_yo...
https://www.schneier.com/news/archives/2010/11/bruce_schneie...
It works pretty well. Different password for each site, I only have to remember a few things, and it would take several compromises (and a weirdly dedicated attacker) to work out my algorithm.
For example, my 'insecure' fixed part might be 'Tenk5$' (I recommend including uppercase, lowercase, a number and a symbol in that part to get around idiotic password requirements). Then my algorithm could be 'the last 5 letters backwards, skip the first vowel'. In which case my password for HN would be 'Tenk5$rtani'.
Some need Lower-/Uppercase, some with numbers, some with special Chars, some restrict to minimum of x chars, some use a maximum.
Your system works not for all things, i use a similar system, but store a bunch of passwords with last pass. Only really important passwords are in my head.
I keep meaning to collate idiotic password rules so you can see for sure which patterns work in all of them, but I've never got around to it.
That has not worked well for me. I have lost a small amount of bitcoin, and some encrypted homedirs and encrypted hard drives.
Use that algorithm widely enough and several compromises are guaranteed. The only thing protecting your password is that url manipulation.
password reuse < own memory/manual storage < synced unencrypted 3rd party storage < synced encrypted 3rd party storage < custom encrypted storage < some custom crazy HSM which doesn't allow you to get more than X passwords per minute and notifies you on each get()
There's another dimension for cross-platform support somewhere in there. At the moment if you want your passwords saved and shared between desktops and mobiles, the best solution I'm aware of is 1password with separate sync (dropbox/icloud) - and you're still trusting the 1password app. You can go further, but you're starting to destroy usability on the way. Lastpass / 1password is still a valid choice that's better than many alternatives.
It targets the local autofill functionality in the browser, so it could conceivably have occurred in any password manager with browser/autofill integration. Including those that use a local password store.
What's happening is that this extension auto filling the password in unintended sites. Where it is getting passwords from (offline or from cloud) is immaterial for this case.
This bug could easily occur in Chrome/Firefox's built-in password manager autofill, though I must admit I have slightly more implicit trust of the developers behind Chrome/Firefox than of Lastpass (instinctively; this may well be unwarranted).
If so, I am a little taken back by LastPass only offering $1,000 to the researcher that found and reported it for fixing. He or she could have taken a different path and resulted in this being used in some complex targeted attack against tech corporations via short-url redirect interstitial pages, or an ad network's javascript, etc. Given the potential damage, I'd say there is a missing zero or two on that reward amount, in my opinion.
How long would you work for $1,000? Some days, a week, two? If you spend more than a week on this problem it seems not worth to report it... On the other hand, if you set the incentive for bug bounty too high I imagine all sorts of cranks pop up, that want to show off bugs that are not there, and resources will be bound to this task -- they have to be verified, and analyzed even if its a bogus report (and in the worst case it will not accomplish anything).
Where is the middle ground?
Probably doesn't work out, but it's what came to mind as a way to deal with the balancing act.
You might not work for long on a $1,000 problem, but other people sure will. College or high school students, people in a country with low salaries such as Ukraine...
https://bugcrowd.com/lastpass
Further to that though, we now know that this problem is fixed in LastPass. We don't know about other password managers. To that end, LastPass is now a better option than it's rivals.
Only when you believe that all password managers are equally secure from the start.
There are many reasons to believe that this is not the case. Storing passwords in a cloud service is quite a red flag. Then there is a former employee stating on Twitter that part of the codebase is very neglected:
https://twitter.com/ejcx_/status/758081553712820225
I put more/less secure in scare quotes, because my point is really that fixing one particular bug certainly closes that one particular attack vector, but security is not a progress bar that goes from 0 to 100.
What this write-up does in my mind is really highlight the risks that come along with using a complex piece of software to manage your passwords. We tell users they can use password managers to safeguard their passwords and increase their security. We talk a lot about the usability trade-offs which password managers entail, but perhaps not as much about the security trade-offs!
Um...it was a really stupid mistake. Writing your own bug-prone regex here instead of using an existing, trustworthy function is just really bad. Especially when the consequences of a bug mean a hacker can steal someone's passwords.
You should really hope that any company that prides itself (and bases itself) on security would never release this bug. It absolutely lowers the reputation of lastpass.
Have you got a mechanism you could post here for them to do so?
It's far too low to motivate a lot of people to look for bugs, and to me suggests they're not serious about protecting their reputation if someone does find such a company-destroying bug.
That was an actual argument on a thread about Facebook underpaying bounties.
Of course it's illegal/wrong to sell an exploit to third parties, but that doesn't stop people from doing illegal things as long as they get money for it. You just don't know about the issues that are sold because that's obviously not going public.
(This is of course orthogonal to the fact that the black market does not want these vulnerabilities.)
Criminals will always be looking, but the odds of finding vulns against a company that pays decent bounties should be far lower than against one paying a pittance, since more people should be looking due to the greater potential reward.
Also, in this case, I think that the amount of damage the company has avoided due to the vuln leaking through non-responsible disclosure is far more than $1000. Deleting photos on FB is nowhere near the same class of seriousness.
The company STORES PASSWORDS. Leaking them is serious.
Regardless, if a company isn't willing to demonstrate they value security to my satisfaction I won't be a customer.
The only problem I have is with the virulently bogus meme that companies should pay more for vulnerabilities because otherwise the "black market" will outbid them. No:
* The "black market" does not in fact want these vulnerabilities.
* Finding a vulnerability and then not using it to to enter into a criminal conspiracy simply isn't praiseworthy, and reasonable people don't have to paid not to do that. It's hard enough to do this kind of work in a society that believes there's something sketchy about finding vulnerabilities at all, without the constant chatter about how maybe they could just make a living by enabling crime.
* The argument doesn't even make logical sense. If the vulnerability is easy to find and exploit (as this one was), then no matter how severe it is, it doesn't command a high price because you could spend less money to independently rediscover it. Moreover, there are surely many other vulnerabilities to be found in the same target. The economics of the argument are all wrong.
That's a weight off...
I have no idea who you think you're replying to, but they're not my points dude...
Felonies exist and people still commit them. Should they? God no. But people with a lower moral code exist and they can be flipped to do "good work" if there's enough money for them (and I think you should get more money in general for your important work anyway). I find the notion of your profession only consisting of good people highly offending to the rest of the world.
You know who does fine in a world where that's the norm? Facebook. No matter where vulnerabilities get valued at, they will be a rounding error expense to Facebook.
You know who does not do fine in that world? Anyone smaller than Facebook.
Thankfully, that's not the norm in the real world. Unfortunately, the real norm is: if you pay a bounty at all, random people on Twitter and message boards will claim you're being negligent by not paying more for them. The lesson then is: don't offer a bug bounty. All you're doing is attracting negative attention.
You know who does fine in the real world where that's the norm? Apple and Cisco. Really, so does Facebook, despite the bullshit flak they take for their bounties.
You know who does not do fine in the real world? End-users.
If you're interested, all our data formats are well documented for review: https://blog.agilebits.com/2013/03/06/you-have-secrets-we-do... You might also be interested in the security white paper for our hosted 1Password service: https://1password.com/security/ (White paper is linked at the bottom of the page.)
We have a dedicated LastPass import option. See here:
https://support.1password.com/import-lastpass/
If you encounter any trouble please write into support at agilebits dot com and mention "Kyle" somewhere in the body of the email and I'll get notified. You should be fine though, but every once in awhile we have someone encounter trouble with the import from LastPass.
I checked out the pricing model and didn't see anything that made sense to me as an individual user. Is there any plan for an affordable individual plan (in the range of 10-20$/ year)?
As a Mac/IOS user, I don't see myself shelling out 60$ for a desktop license and then another 10$ for an IOS license on top of it. I'm sure your profit margin is great, don't get me wrong, but as a buyer that is just overkill.
I'd say many people don't need the Pro features in the iOS version, it's possible that maybe you won't either? Depends on how you use it I guess. Probably the biggest reason to get the Pro features is multiple vault support (you can add additional vaults that were created from the desktop versions). With the free version you only get the one vault.
If you use the app like most people, you'll be using it dozens of times a day. Even if it's in small interactions those do add up. I've been trying to convince the team to add some sort of individual statistics that were stored locally for users to see, but I suspect this would probably help you decide that regardless of price it would be worth while :)
In the end, the choice is yours though. We certainly want to hit the price point for all users that we can, but we do have to keep the lights on or the product disappears. We aren't priced at a point where we're trying to acquire users in bulk so we can sell to another company. AgileBits is privately owned and has never taken outside funding. Something to be aware of when you're talking pricing I suppose. At least one factor.
Kyle
AgileBits
Purchasing 1Password for 65$ gets the current major release with no updates?
Subscribing to 1Password Families for 5$/month: Lets me sync passwords between all of my desktops and phones? Can I sync an encrypted password database or is this done as a hosted cloud solution by 1Password?
$65 gets you a single license for Mac and Windows. This can be installed on multiple Macs or PCs you own, but is generally for 1 single person.
You get all updates to 1Password 6 for Mac for free, and any updates to 1Password 4 for Windows for free. On the Mac side, we are planning a 6.5 release in the next couple months. Most of the changes in this release will center around 1Password Teams/Families/Individuals (the subscription option). Along with bug fixes that likely impact both. We are likely nearing the end of the road on version 6 after that.
With the $5/mo you can technically do two things...
1. You can use the hosted solution 2. You can create local vaults (like the standalone version does) and sync those using Dropbox, iCloud or Wifi (to mobile devices)
So, with the subscription option, you get both. Whether you use the hosted part of it or not is up to you. However, if the subscription goes into frozen state (unpaid) the app will go into Trial mode, which limits you unless you re-subscribe or purchase a standalone license.
I currently use both local vaults and the vaults for my work Team and Family account. Mostly the local vaults are for testing purposes but it all works fine with a subscription.
Let me know if that helps :)
Kyle
AgileBits
The hardest part of the migration for my parents were 1) demystifying the spaghetti mishmash my Dad had in place to manage his passwords, 2) getting Dropbox set up correctly between Mom & Dad for vault sharing, 3) training my Mom how to use, and 4) educating Data on how to manage website edge cases.
I would hope that 1PW has a LP migration tool, but if they don't, Dad was able to clean up his historical garbage one by one. The password capturing process in 1PW is good enough that this worked nearly seemlessly.
Finally, I've had nothing but positive results from posting questions in the 1PW forum.
Heck 1Password mostly works under Wine, except perhaps there is no unlock on Secure desktop and bunch of other usability things.
Yea, we hear you there. I (and others on the team) wish we could make this happen, but priorities are a tough one. Linux in general didn't fit all that great in our standalone license model before, along with being closed source. Now with the subscription option for individuals (new today), families and teams we have made the payment side a little less of a concern but we still have the closed source nature of things making Linux a harder target to hit.
We're probably in a better position now than before though. Every time I asked a Linux user who wasn't asking for this they said they had no interest in paying for closed source software. I wanted all the positive response I could get to show to the decision makers but I fell short in getting it.
This is all to say it's simply a complicated situation. It has to either make money to pay for its development, or the others have to offset it enough that it's a win for us so we can keep the lights on.
Hope that helps a little anyway. I know it's not the answer you wanted but I hate leaving people like yourself wondering why it feels like we aren't listening.
Kyle
AgileBits
I can tell you one thing that is indisputably better about 1Password though.
Support.
Quite literally. We have a team of over 30 customer support personnel (in addition to myself and other developers who pitch in for a part of our day). We're here to help if you run into problems, encounter a bug, have feature requests, or generally just want questions answered about how we do things or why something is done the way it's done.
Keepass, as noble as it is to have an open source and free product, is run and improved by volunteers. I realize that not many people on hacker news really care that much about support since we're all typically very capable people, but as someone who has been with AgileBits for nearly 5 years now and seen a whole lot of the weird edge cases that can exist because some webpage is doing something incredibly weird or some particular computer setup is causing problems. It can be really helpful to know that there are people who can look into these things for you instead of having to know it yourself.
1Password does have a 30 day trial (both for our standalone product and for our individual/family/team subscriptions). You can try it yourself and see how it works for you. And as always, if you have questions during this time you're welcome to get in touch (support at agilebits.com, mention my name if you want and it'll notify me) and we'll help you get things setup. We think the product speaks for itself and we're happy to fill in any gaps if you need more :)
Kyle
AgileBits
I am actually not sure what I would need support for either, it seems pretty basic. I am simply storing passwords. It doesn't seem too complicated. And maybe this is because I am a tech person, so maybe I am looking for the more technical reasons why the software may be better rather than how the support excels. Because if keepass had a problem I know ways to get support anyway, either via a Stackexchange site or IRC. So I am definitely a bias group.
However I do not care if the software is open source or not. I know some people do care about that, but the people I talk to do not. People in my age group seem less concerned about open source or closed source.
I'm more curious if there are some kind of features in the product itself that make it better than keepass? I do not have a family so the family cloud version of 1password is not useful, though I would not be opposed to a cloud version of 1password for an individual. I currently store my keepass in dropbox and have that synced to all the devices I use.
I work remotely for my job. I do travel several times a year as a result and when I'm gone I have other family members watch my house. Before 1Password Families I had to find a way to easily get my wifi password, my garage door code, and various other instructions and information to whoever was watching my house.
With 1Password Families I simply create a vault in my Family, add my items to it and invite the person who will be watching my house as a guest (or in my most recent case, granted my brother access to the vault).
In the first case, the person simply signed up, installed 1Password and they had access to the data. In the second case, my brother simply unlocked 1Password and the vault was there.
When I get back home, I simply remove access and those things disappear from their devices. None of these are so important that I have to change them, but, that's another step as well if necessary.
But that is how easy it is to share and use vaults in 1Password Families (and Teams).
I also love that using this I can add family members, like my parents, and it handles all the syncing for them so I don't have to micro manage it with backups and other stuff. It's a far more seamless experience. And since I hold the keys to the family kingdom, I can also reset their master password for them if they forget it.
Now, you might think you have no use for this, and that's fine, but it's an example of how someone who doesn't have an immediate family (I'm single, and childless) was able to use 1Password Families in a way that wasn't obvious when I first set out to use it for myself.
In terms of features that differentiate us from Keepass, I have never used Keepass so I am not able to speak to what we do differently. I'm sure there are things each of us do better though.
There is a trial version of 1Password, so, you could use it and see how it stacks up for yourself. I'd be very curious what you find better or worse so I can pass that feedback along to our team. Completely optional of course.
Kyle
AgileBits
If you have any questions that we might be able to answer, please shoot me an email. kyle at agilebits.com, or support at agilebits.com. I work on our Mac/iOS teams and security teams. I can probably answer most of your questions and at least get them in front of people who can answer them.
I really hope you're not making this work with AgileKeychain, we've put that one out to pasture. :)
Kyle
AgileBits
We've got pretty good OPVault support going, but your guys' RPC protocol is not open, right? Between mini and the browser plugins?
And also correct on the mini to extension protocol, there is no public documentation for that, primarily due to that being something we really need to be able to change as necessary.
We are really curious to see what you've come up with though :) So please keep me in the loop if possible!
Kyle
AgileBits
I never trusted "cloud" (read: not yours) password stores. I have been using KeePass and manual syncing, but I had my doubts about it too.
This looks perfect and simple!
A system is as secure as its weakest component.
It also doesn't try to NIH some complicated database format or syncing technology but instead uses well-established software (git, plain directory structure and gpg-encrypted text files) which makes it robust, flexible and future-proof, and also responsive to changes in cryptography as it benefits from upstream GnuPG updates. You can use any PGP key structure you want, or even hardware PGP devices like the YubiKey.
KeePass on the other hand seems to be based on mostly homegrown techniques written by people with no or limited understanding of cryptography. (see e.g. [0]) That said, I don't know how much KeePassX continues this trend - but it's based on the same file format so it presumably has to reimplement at least some of KeePass's homegrown crypto.
I don't know how much more convincing you need, but personally I wouldn't even dare consider using anything other than `pass`.
[0] https://news.ycombinator.com/item?id=9727297
I use keepassx, which requires manual search, copy, paste but it can store its vault on a cloud drive, mobile etc. and can have a key file or password.
Even if you don't hit the enter key/submit the form it is still possible for that incorrect window/app to grab your keystrokes.
(Apart from "don't use services that require you to share passwords for a single account". Alas.)
So that seems like a reasonable way for people to share them. However, I only use it for myself so I may not have thought of all the gotchas.
Here is their security white paper : https://www.dashlane.com/download/Dashlane-Security-Whitepap...
*every few major releases
I found this alternative when LastPass was acquired by log me once. I was not happy with this. This app doesn't have hacking or vulnerability history like LastPass.
They also have a dedicated import for LastPass. https://www.enpass.io/docs/desktop-mac/import_lastpass.html
On the other hand, using regexp to parse the URL when it's such an obviously security critical code path... just, why?!
[1] - https://bugcrowd.com/lastpass
As we can see from avlidienbrunn2's response [1] sometimes it's not about the money. It's just fulfilling a natural curiosity about a product, maybe getting your killer write-up of a shocking bug to hit the top of the HN frontpage, etc. So in this case perhaps the bounty program is as much about establishing a legal structure for a whitehat to operate under than to fairly compensate ad hoc pen-testers. I wish they paid 10x or more for this bug. But I'm glad at least pen-testers can report these bugs without [as much] fear of reprisal.
[1] - https://news.ycombinator.com/item?id=12171753
Personally I lost a lot of confidence in them when they got acquired and switched to 1Password, paying very low bounties for critical security flaws further hurts my confidence in them.
From my vantage point, the logical conclusion to the comment you just wrote is that companies should avoid offering bug bounties. They just attract negative attention.
(I won't use LastPass, and have recommended 1Password --- but Tavis Ormandy is looking at 1Password right now, and I'm guessing they're going to end up disappointing HN too.)
So the end effect is more bugs found by "white hats" rather than "black hats" because the bounty has focused the "white hat" efforts on your program. (Or encouraged them to look at all.)
I'm likely to poke around a site with a bug bounty even with small sums just because it hints at a more formal process and also likely means they have a sensible policy about not going after testers.
Bug bounties are as much about signalling than encouraging "black hats" to suddenly turn to the light side.
The purpose of a bug bounty is to incentivize researchers to target specific pieces of software so that vendors can benefit from that attention.
Your rationale would be a valid rebuttal in your world no matter what the amounts in question were. $500? Incentive! $50? Incentive!
We can agree to disagree because the perspective really wasn't for you, it was for everyone else reading that will share a sentiment they've felt but never articulated
There are two kinds of vulnerabilities in the world:
The kind organized criminals will pay tens of thousands of dollars for, and the kind they, like any Internet rando, will pay $50 for lulz.
If you think this dumb regex bug is worth the same to organized criminals as a Chrome sandbox escape or drive-by reliable Flash RCE... well, people think that about a lot of bugs, I guess.
This LastPass bug is terrible. I was already inclined to warn friends against using it (but my other friends have beat me to that punch many times before). The bug looks terrible for LastPass and its mere existence is damaging to that project.
But that doesn't mean the bug has significant monetary value. As someone else here cleverly put it on the last dumb bug bounty thread: you can smash a car with a sledgehammer, but that doesn't make the sledgehammer worth the value of the car.
Perfect analogy, I'm putting that in my back pocket.
Bug bounty programs, presumably, prevent unsavory exploits at some point in the future. Having this responsibly disclosed was damaging still, but cost LastPass less money than having it exploited later.
I'm not sure where that falls on your "significance" scale.
No, suggesting otherwise is saying that a bounty program with high enough rewards can reach both legitimate security researchers and sketchy folks. This is in no way a slight on the first group.
If you're a 10 you will disclose responsibly regardless of a bounty, and if you're a 1 you will disclose to the highest bidder. The rest will weight profit, ethics, and risk in some ratio depending on where they fall on the scale and decide to act based on that calculation.
The company has to price their bounty on a few factors: how much they can afford to pay, how much a bug is worth to them (eg damage to their reputation, fines in the event of a vulnerability), and how important it is and to have researchers looking at their product instead of another product.
I agree with you that companies should not be required to pay people to prevent them from launching criminal conspiracies. But this is not a perfect world and people are not so black and white in their actions and motivations. There is no point trying to optimize your bounty program for the 1's or the 10's. Therefore, when optimizing for the rest it makes sense to pay as much as possible within the constraints I mentioned (in the previous paragraph) in order to tip the scales in your favor for the largest part of the spectrum possible. Right now the tech community knows about this problem with LastPass. If this exploit had made it to the wild things would've been much worse for them from a PR perspective.
I am hoping that the $1000 cap on the bounty program came from careful consideration of these factors, but my gut tells me it was a number handed down from management.
Why not? Sure, you can't accuse them of being dishonest, but why would simply announcing an action make it beyond reproach?
Why not? URIs are at least able to be tokenized perfectly well by a regular expression. You have to do it right, but there's little guarantee that your non-regexp code will do it right either. I glanced at that regexp and immediately recognized several potential problems with it... will I be able to do that with your non-regexp code?
To concretize the "several potential problems": 1. You generally don't want to parse arbitrary protocols, you should do something like (http|https|file) or whatever set of protocols you are ready to receive. Usually you're better off treating anything else as "not a URL", but consult your local security context for details. 2. Failing that, you want at the very least .⁎? to stop matching at the first :, or if your engine doesn't have that, the protocol ought to be matched with something much tighter like [a-z]+. And I do mean + and not ⁎, because you probably don't mean to support an empty protocol before the colon. (You may mean to permit URLs with no protocol, but that's (.⁎?:)? .) 3. Domains should be parsed more tightly than "not a slash". 4. Also, I have no idea what the @ was doing there. Perhaps it was trying to be $; URL parsing should always end with the "end of string" matcher to avoid problems similar to this. It should also start with the start-of-string matcher, which this one doesn't, for similar reasons. 5. Bonus critique, anything using regular expressions to URL-encode or decode is very suspicious; strongly prefer built-in functions that do this.
I literally saw all this faster than I could type it; does your non-regular-expression based code have this property?
Regular expressions aren't bad. They're hard to write properly, but still probably easier to write properly than anything else. It turns out the underlying problem is fundamentally hard.
(Had to use an alternate asterisk to get the RE expressions correct with HN trying to format it.)
This article is a perfect example of why not.
A while back I whipped this up: https://gist.github.com/pmarreck/2956396
which seemed to work well (although it was a bit slower, I probably didn't know about exponential backtracking at the time and that could probably be revisited). It won't gather multiple name/value pairs though, but it will cut out and name basically every other part of the URL.
https://mathiasbynens.be/demo/url-regex
https://lostechies.com/chadmyers/2010/11/20/parsing-a-url-wi...
https://stackoverflow.com/questions/27745/getting-parts-of-a...
What do all these have in common? They all demonstrate that it is hard to write a regex that parses URLs.
Regex's hide programming mistakes because they not only become harder for humans to parse as they get more complicated, but also there isn't simple programming code to handle potential security vulnerabilities in-line with the code. It also hides the [at least] two considerations of secure programming: designing a secure function, and handling the function securely.
You might also want to check the definition of "simple". Probably doesn't mean what you think it means.
You can't look at regexs in isolation, see that a task is hard, then declare them unfit. You have to consider them as one of the many choices and analyze the cost/benefits of the whole suite of options.
I guarantee you that anyone who has said "Oh, gosh, this is hard, I'll just start using indexOf and substring operations" has written code that is just as broken, only in ways much harder to tell.
Which is probably why everyone here thinks it's better to not use regex. You didn't write better code... you wrote code that hid its brokenness better. That's not a good thing!
Again, my real point here is not "regexes are awesome in every way"... my point is that I literally glanced at that code and saw several ways in which it was wrong. Does your alternative have that property?
Also, some of the difficulties of regexes are accidental, not essential. Take something like the recent Perl 6 efforts for parsing and you're far better off in every way using that stuff than trying to bash together string-manipulation-based parsing, or whatever other alternatives you may be thinking of. The Perl 6 constructs will be more readable and more maintainable. (Perl 6 is crazy in a lot of ways but the parsing support is best-of-breed.)
"Why not? URIs are at least able to be tokenized perfectly well by a regular expression."
"5. Bonus critique, anything using regular expressions to URL-encode or decode is very suspicious; strongly prefer built-in functions that do this."
And the problem is probably more accurately stated as "be suspicious of any function implementing encoding or decoding" rather than focusing on the regex part. Use the correct standard function. Don't bash something together yourself. They're actually pretty easy functions to write if you know what you're doing, but it's even easier to use some tested already-existing function. In fact, it's so easy that the fact that you see someone bashing together a URL encoding or decoding function almost certainly proves that they don't know what they are doing, which in turn means the URL encoding or decoding function was written by someone who doesn't know what they are doing. Unsurprisingly, these are, well, to quote myself, "suspicious".
Yes, that logic applies to URL parsing as well! Unfortunately, browsers make URL parsing extra hard, which is really stupid, so you end up with more crap in Javascript than anywhere else. Even then you ought to prefer someone else's tested solution over just smashing out a regular expression; however, it is not a knock on the tested solution if it is a regular expression-based solution.
Using something illegally means you run the risk of going to prison. Let's say there's a 1% chance you get caught, the prison sentence is 10 years, and the evil hackers will pay you $20,000 for your bug. Let's also say that you're a mid-career software engineer in the US, and over the next 10 years you expect to make $2M (after taxes).
This means your expected outcome over 10 years is $20,000 + (0.99 * $2M) = $1.98M. With Lastpass's bounty you end up with $2.001M.
With these assumptions, you should be paying Lastpass to find bugs in their software! Of course, if you're not in the US, you probably make a more reasonable salary (read: less), taxes are higher, and the risk of getting caught is lower.
That would be $300K per year pre-tax (assuming current 2016 tax rate of 33% for the 200-400K bracket). Is that really a normal mid-career salary?
I need to change jobs if that's the case...
https://en.wikipedia.org/wiki/List_of_computer_criminals paints a picture that prison time is mostly a US-only thing.
Some people want to watch the burn. An attacker could make it known anonymously and LastPass will never recover from that onslaught.
I am a lot taken back by it. This wasn't a minor bug. I don't care if $1,000 was the published maximum payout under their bug bounty program - for something like this, the payout needs to be representative of the damage that would have been done to their reputation had this bug been discovered and exploited by bad actors. Given that reputation is everything in this space, any well-publicized incident using this would have effectively rendered the company dead within days.
Here's hoping they reconsider the award amount (though I'm certain they won't).
I really don't wanna ask the companies for money but it just seem so... underwhelming for me. (3 out of 3 rather big companies just gave some thanks)
It would be like someone walking up to you on the street, handing you something they think is valuable, and then hoping that you'll want it and pay them for it.
The first thing you should do is check and see if they have an official bug bounty, if they don't then contact them and ask them if they had one.. say something like "because you saw some things on their site that concerned you, but wanted to know if it was worth the time exploring further" .. this is assuming you already found something. The goal of this is to get them to try and offer a bounty.
If they don't offer a bounty, then if you want to be responsible, you can just disclose their vulnerabilities to them, and accept whatever thanks you get.
If you're explicitly doing what you're doing to try and get some money out of it, then your time would be better spent focusing on companies that have well published bug bounties.
When LastPass gets breached, they're not directly responsible for what an attacker does with the passwords.
When another site/service gets breached, they have to spend a lot of time making it right to the customer again (e.g. rolling back transactions, compensating for lost or stolen funds, etc.)
It does seem like an extremely low bounty for a security bug that severe.
I mean, in a 100% libertarian world, this hole would have been put up for auction to the highest bidder and LastPass would have had to ensure they were the highest bidder in order to close up the hole and basically save their business.
I think it works the other way around.
I've been defending LastPass and recommending it to everyone till today. Now I'm thinking about how I might have to 'pay' for a software vulnerability in some private (read:unauditable by me) code. All the comments about offline, local backups make sense to me.
But the points I usually make are still valid, like:
1. I can go to any computer with chrome and get access to all my passwords, so don't have to carry my passwords with me everywhere.
2. Don't have to worry about storing passwords properly since lastpass is a good company and they know their stuff about protecting the customers' data.
3. Password capture. It might seem like a tiny feature, but I'm too lazy to remember opening an app and entering my credentials whenever I create an account or login into an old account.
4. Mobile login, although a paid feature, this really changes my life. If I don't trust a computer enough to login via chrome or something else, or want my secret notes, I just open up my phone.
But all the above features meaning nothing when it comes to the chance of compromising all my passwords (except bank info, of course)
I'd like to hear the thoughts of anyone else who uses lastpass and what they think.
But I don't think it's worth getting excited about a single lastpass bug. Everything is vulnerable. There will be more of them. Chrome itself had 105 security issues, just this year (https://www.cvedetails.com/product/15031/Google-Chrome.html?...) - a few of them potentially leading to your passwords being exposed without any extensions.
Upgrade often, don't do stupid stuff, keep backups, and you'll be more secure than 99% of people. Evaluate your choices from there.
Well, that put it in perspective for me. I just googled the vulnerabilities in offline password managers like Keepass/X and 1Password. And oh man, I was pretty shocked to see even the offline ones could be broken into.
I think I just had a crisis of faith.
>you'll be more secure than 99% of people
Thanks. I guess since I don't store very sensitive info (financial, etc.), and the important services - Google, Github, Atlassian, AWS use 2FA. I guess I don't have to be paranoid.
I love it how I get to decide who or what gets to see the encrypted file.
Now hopefully the Keepass audit will not reveal any issues in the encryption.
This matters because even if it's client-side encryption, the encryption code just got downloaded when you opened the site so if the server or the network was compromised, you got compromised. [0]
With Keepass, the only time you run that risk is when you download Keepass.
[0] As far as I can tell, this is the core argument of tptacek's "javascript crypto considered harmful" rant (https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...). I'm not sure, because it's written worse than his most drunken HN comment, but I believe it is.
Like with all decisions this is balancing risk/reward. The reward are all the points you have already expressed that I also love about LastPass. Currently I believe the risk is fairly minimal assuming you use 2 factor-authentication. Though I might turn off autofill now as an extra precaution.
For example. I use KeePass to store all my password. I keep my KeePass database in Google Drive, so any change to the file will be updated. because of that I can use KeePass on any machine that has access to Google Drive (I also keep executables for various systems in drive). Furthermore, there are number of free mobile applications for KeePass which can hook into GDrive and you can use KeePass on the phone too. And lastly - browser extensions which let you use your KeePass to automatically fill & save passwords (I don't use it, though).
Sure, KeePass requires a bit more of an effort compared to all-in-one solutions such as LastPass. That is the price you pay for not thinking about possible security breaches in the cloud.
Integrating with the browser is probably a bad idea, it shortens the exploit path from a webpage to your password store.
Using a standalone application and using the clipboard would require a malicious website to break out of the browser and then break into the password store process, which could in principle run under a different user and interact with the clipboard through some broker process.
This bug doesn't seem to have anything to do with the cloud.
FTA:
> The bug that allowed me to extract passwords was found in the autofill functionality.
I don't mean to be the advice bird, but maybe you can point all the points you made to your superiors and make them re-evaluate their choice. If they're a huge enterprise, then I understand
Maybe a computer you can trust but I wouldn't say any computer. I consider the shared PC you'd find in a hotel business center to be the digital equivalent of a diseased hooker. I'd be impressed if it didn't have a key logger installed.
> 2. Don't have to worry about storing passwords properly since lastpass is a good company and they know their stuff about protecting the customers' data.
Not being OSS I don't think that can be proven. It boils down to "Trust us, we're smart".
> I'd like to hear the thoughts of anyone else who uses lastpass and what they think.
Trust noone and put your faith in OSS (KeepassX, pass, etc).
I think you'll be impressed in a lot of cases than. I would be surprised if more than 15% of shared PCs have keyloggers active on them.
Still doesn't mean i'm going to login to anything on them though.
This was a client-side bug and so surely doesn't depend on the fact that your passwords are 'stored in someone else's cloud'?
i.e. If there was only local storage of passwords this vulnerability would still be there.
(Also worth noting that lastpass encrypts your remote and local store with a key which is presumably only stored hashed and salted on their side)
The idea is good, just not sure about SHA-256...
Or there could be several modes and a database of websites that automatically picks a mode based on the website. Which leaves you remembering modes in the worst case scenario, or trying a few of them out.
I think an acceptable solution can be made by analysing the password requirements of the top N websites, then coming up with a good scheme that works on most, and an alternate scheme that works on the rest. One mistake is usually allowed everywhere.
Don't use a password manager, remember your passwords, or reset them all the time. It's a conceptual vulnerability, and if you read hacker news you are better than this.
1. "Salt" my email usernames with the name of the service (johndoe+reddit@example.com)
2. Use multiple (long) password bases depending on the type of service (eg website vs app)
3. Combine the password bases with a cipher/salt based on the service name and my username
I'm guilty of not rotating passwords on a regular basis, however.
Depending on the type of service, `password_base` changes. For example, HN uses a separate one from Gmail for Business. Likewise, `service_cipher` and `username_cipher` are simply that: truncated ciphers of the service name and username. Lastly, `special_chars` is used for pesky sites that want special characters outside the range provided by my password base.
I'd like to think my system is very difficult for someone to crack without gaining access to a large number of passwords. The only limitation is that a few sites have limits on password length(!) which requires using a shorter base or even truncating the password entirely.
http://www.zdnet.com/article/lastpass-zero-day-vulnerability...
"Also, this would not work if multi factor authentication was on, so you should probably enable that as well."
If you have something as important as a password manager (ie something that holds the keys to ... everything), then MFA is a must. If you use LastPass without MFA, then you're probably asking for trouble.
An example is Vault [0].
Encryptr [1] is another alternative: it claims that "all of your data will be saved in encrypted format in our Zero Knowledge [2] cloud".
[0] https://github.com/hashicorp/vault
[1] https://spideroak.com/solutions/encryptr
[2] https://spideroak.com/features/zero-knowledge
Zero knowledge is merely the fact that spider oak only holds encrypted backups of your files and it has no way of seeing them. LastPass tells us the same thing.
There are fair number of open source alternatives that allow you to store secrets in the cloud:
It's probably not worth attempting to convince certain people. Not only Encryptr, but even other ones [0].
Oh, and I'm not even remotely affiliated with SpiderOak.
[0] https://spideroak.com/solutions
Thanks! :-)
Essentially, LastPass made the mistake of writing code which said "If you see `example.com` anywhere in the URL - assume that you're on the right site.
LastPass will allow you to automatically fill in the username and password as soon as you visit a site (I think this is an optional feature).
An attacker convinces you to visit "badsite.wtf/@example.com/". LastPass sees the "example.com" and autofills the password field. The site has some JavaScript to detect the filled in details - and steals them.
Also, what's the return value of the funcion?, and why are there 2 variable named URL?
What's the difference with simply going to "http://twitter.com"?
This looks more like a bug than a vulnerability, what am I missing?
var parser = document.createElement('a');
parser.href = "http://example.com:3000/pathname/?search=test#hash";
parser.protocol; // => "http:"
parser.hostname; // => "example.com"
parser.port; // => "3000"
parser.pathname; // => "/pathname/"
parser.search; // => "?search=test"
parser.hash; // => "#hash"
parser.host; // => "example.com:3000"
Since malicious attackers have complete control over the page you're seeing - they can simply replace document.createElement with their own function. And instead of returning a DOM object, they can return an object that returns whatever they want in .hostname
For desktop browser extensions that are properly using the frameworks, the extension's Javascript runs in its own execution context so the page cannot redefine variables. This protected 1Password when we discovered that a certain page had redefined the global JSON object, which provides parse and stringify functions among other things, to be the number 3, i.e. a numeric constant called JSON. :'D
We really try not to call it "Classic" or anything like that. It's standalone, you're in charge of upgrades, syncing and backups and stuff like that. It's also not designed for sharing (at least to the degree of the Family and Team solutions).
That said, we don't have any immediate plans to remove the standalone products. However, if a vast majority of our users switch to 1Password Family or 1Password Teams (and as of today, an Individual plan!) then it doesn't make a ton of sense to keep the standalone product around. So, it's probably one of those speak with your wallet kind of scenarios.
I'll certainly pass your feedback along, it sounds like you'd like to keep it around.
I hope that helps answer your question :)
Kyle
AgileBits
But the real important thing to consider is whether the protection you would get from a hosted solution so above and beyond overkill that it matters?
If you're curious why I feel that way, we have written up a white paper on how 1Password Teams (and therefore Families and now Individuals) stores and secures your data.
https://1password.com/files/1Password%20for%20Teams%20White%...
We designed 1Password so that we cannot know anything about your data. We also designed it knowing full well that our servers would be a target. So, we designed it in such a way that if a malicious person were to acquire your data there's more or less nothing they can do to acquire the decrypted data.
What we settled on is having two secrets. Both of which are not known by us. The first is your Master Password, something that you're likely well aware of having used 1Password already. The second part is an Account Key, which is a random 128-bit key generated locally. These two things are never given to us and should never be shared. They are both used for the cryptographic functions in 1Password. Without them both, you can't see the decrypted data.
This is unique in that it actually protects weak master passwords. That's the big deal to worry about if our database of user data is compromised. The first attack is to start running password cracking tools against it to try to find the weak passwords. Except in this case, there are no weak passwords because even if your master password is "a" the attacker still needs your Account Key, which looks something like this:
A3-Z4JZ6V-P9BALK-S6J69-FAXCN-LTDY8-T3QHJ
So, now a password cracker is going to have to guess all those combinations of weak passwords against something much much stronger as well. I wish them luck because the math more or less makes this impossible if a user uses a strong master password as well.
There's some math in the white paper if you're curious about more.
Knowing how it works and how extremely unlikely it is that I am such a target that someone is going to literally spend millions upon millions of dollars trying to crack my account (and still likely get nowhere)... I'm small fish, it just isn't worth it to even try.
Either way, for the sake of learning (I love learning, so I always assume others do as well), I would recommend reading the white paper, if not only to gain some new knowledge that you may not have been exposed to previously. If you have, awesome!
As always, if you have questions let me know!
Kyle
AgileBits
Anyway, I gave up on both 1Password and LastPass. I've been a 1Password user for about 2 years before I switched to KeePass.
To be more specific, for the desktop (OS X, Linux, Windows) I use: https://keeweb.info/
For Android: https://play.google.com/store/apps/details?id=keepass2androi...
And for iOS, though be warned this one is subpar: http://minikeepass.github.io/
All 3 apps are open-source. This is important because open-source will not die for as long as there is demand and more importantly, you own it.
No, I'm NOT against proprietary software, as I said, I gladly paid a premium for 1Password. However their Windows client is basically unmaintained, their new "modern Windows" app is still alpha and doesn't work with Wine and of course, they have no Linux support. Most aggravating is that they are clearly switching to a subscription model, with all of their development effort going towards it lately. No more Everywhere interface for OpVault, no new sync options other than Dropbox and iCloud, etc. In other words I'm tired of bait and switch models and one is in progress here.
https://start.1password.com
It is $2.99/mo when billed annual ($3.99/mo month to month), includes all of the applications as part of the subscription price.
It is otherwise based on the same technology as Family and Teams options. It's basically Families with only 1 user.
Context: I'm a new 1Password user who is contemplating use of the extensions for those latter two browsers, and while it seems probable their extension frameworks offer the level of security you describe, I'd like to be certain before pulling the trigger. Thanks!
Hi there!
Yes, all 3 of the major browsers (and derivatives of them) offer the same support for a sandboxed execution environment. You can safely use any of them if that's a requirement you have :)
Kyle
AgileBits
If the website could override extension functions, attacks would already be possible by overriding Regex functions.
The untrusted script can override its own view of createElement, but not the extension's view.
I wonder if a DOM mutation event would be triggered if a content script adds a new link element and changes it's href.
Would I be able to catch that and quickly change the href, before the content script continues to fecth the processed properties?
It is true. See documentation => https://developer.chrome.com/extensions/content_scripts#exec... :
> Content scripts execute in a special environment called an isolated world. They have access to the DOM of the page they are injected into, but not to any JavaScript variables or functions created by the page. ... The same is true in reverse
[0] http://archive.oreilly.com/pub/a/network/2005/11/01/avoid-co...
The same attack you describe could be applied to basically any javascript you cared to write (say, String.prototype.length). The safest approach is to treat the output of injected javascript as untrusted third-party input to your extension code and work from there.
For browser extensions, the URL constructor would be even easier: https://developer.mozilla.org/en-US/docs/Web/API/URL/URL (Yes, I know it says that IE doesn't support it, but IE doesn't have a proper extensions framework, so it's irrelevant to this topic.)
"I see you are posting about LastPass' vulnerability, but you work for 1Password. Please confirm there exists a regex vulnerability in 1Password which is similar in nature to the one that occurred with LastPass."
Put this way, the insanity of the statement is obvious. In questions, it becomes less obvious to the majority of the population, which only serves to spread the insanity to others.
Don't feed the fear with dissonance.
Edit: It is NOT "reasonable" to ask questions with negation in them which assume blame in a piece of software which is, by a rather large assumption, a completely different code base. Reason is based on logic. This question was based on fear and uncertainty, and only serves to spread it further.
You downvoters can go fuck yourselves.
[0]: Stack Overflow Outage Postmortem https://news.ycombinator.com/item?id=12131909
My goal was to settle concern for myself and other 1Password users. That's why I wrote whether a similar vulnerability "does not affect 1Password" instead of "does". My apologies if this was unclear.
I recently started using LastPass after years of reusing the same uncrackable password: !p@ssword123
For me, the biggest pain point is the interface. The automatic form filling rarely works as it should; I click the LastPass icon in the username field, select the site, and it only populates the username (even though there is an input with type="password" right below it).
I then have to: 1) Press ALT+W to bring up the LastPass site search 2) Type in the domain name 3) Find the correct entry, and then click "Show Password" 4) Use my mouse to highlight the password and copy it (there is no quick way to copy the password) 5) Close the tab, go back to the original site, put my cursor in the password field and paste it
And then I have to worry about what password I may or may not have lingering in my clipboard.
If anyone has a better workflow please let me know. I'm envious when I watch coworkers use 1Password to populate a form in two steps using hotkeys.
Then just click the password field and Ctrl-V, of course.
If you're concerned about the clipboard, get in the habit of typing Shift-LeftArrow Ctrl-C after entering the password, to quickly replace your clipboard with a single character.
I'm not sure how LastPass does it, but 1Password does clear the clipboard after a short period of time (configurable, I think 90 seconds by default). I use clipboard logging via Alfred, and can confirm that however they clear the clipboard works to keep them out of its log.
- This is the second serious security incident with them. Nobody's immune to bugs, but I haven't seen a similar history with AgileBits.
- LastPass has, IMHO, terrible UI/UX. Things don't work consistently, there are weird, unexpected pauses that look like malfunctions until something visible happens; it took me a comparatively long time to figure out how to map common actions to the gestures that perform them; and finally, this is way down the priority list, but I find it generally kind of ugly. I suspect some of these complaints are partially linked to the next point.
- Lastpass is more trouble than it is worth in Safari/Mac.
I've used 1Password personally since 2008-ish, and think I've had exactly one nontrivial problem with it in that time, which was my fault. (There was some upgrade-path weirdness with the iOS version several years ago, and I left a device unused long enough that it ended up with orphaned data I couldn't sync. I forget the details of what exactly happened.)
1Password Teams didn't exist when my company started using Lastpass, but I'm hoping to get switching onto the low-priority project list.
You should maybe try and get it on the high priority list. On August 1st the Teams pro plan will increase from $4/user/mo. (introductory price) to $12/user/mo. for new signups: https://1password.com/teams/pricing/
Can't agree with this more. I've had so many issues with LastPass staying logged in one browser across sessions, even though the preferences are set to logout after short inactivity windows and on browser quit. LastPass seemed to lose its preferences like this multiple times, and it made me uncomfortable from a security perspective to not know for sure when my sessions would actually end.
Besides that it's mostly UX issues for me, similar to what you've described.
I also prefer 1Password's pronounceable random password generator vs LastPass's generator (obligatory xkcd https://xkcd.com/936/).
But after the first use of the LastPass Safari extension, TextExpander (or KeyboardMaestro, or a bunch of other tools) won't work anywhere until a after reboot or some other method of disabling SI.
(Without a paid subscription, bookmarklets on mobile still work for free of course. But I found that login flow so cumbersome.)
There are appropriate channels to ask questions like that and appropriate times to downvote. But, hey, I'm not here to offend the hivemind. Please have mercy ;)
Please don't do this on Hacker News.
While I would agree that this place would be better off without judgment, and harsh judgment as I've shown here, the reality is that we all share this place equally with others who do not stop and consider their actions as affecting others thought processes in a negative way. I put this on here to illustrate that point in a non-obvious way, and in a way people CAN understand: anger. It's not the only way of course, but it does get the bug into people's brains quite well.
I appreciate your comment and intent behind it.
I very much agree that downvoting without comment (indeed except for the truly awful ones that would just draw needless noise because of it) is an anti-pattern. But I am occasionally guilty of it myself as well, partly because writing a reply to a not-quite-awful comment costs me a lot of time (even if it's a short cmt).
The greying-out of downvoted comments doesn't help with the perception of receiving a downvote without comment either (makes it feel more harsh, IMO). I'd prefer showing the counts again, actually.
I think an official word holds more clout and is more valuable than any one person confirming for themselves in one version of one browser on one version of one OS.
I understand that, as a user of 1Password's browser extension(s), you may well feel some concern that a similar vulnerability exists, and I don't think it's unreasonable to want reassurance on that score.
But I think your phrasing and framing of the question feels a lot more like a "gotcha" than anything else, and it's that feeling which motivated my prior comment - I'm not an AgileBits dev myself, but if I were, I'd feel strongly inclined to shy away from that question rather than trying to frame an answer that doesn't leave me open to a potentially hostile followup.
1: Defensiveness. It seemed more like an honest question than a pot shot. You seemed to read into it something like "Aha! How about your software fool!?!"
That said, if it were a reporter asking the question, then I would see it as a gotcha, because the use of the word confirm is used as a setup sometimes.
2: Tech bias. Not everyone on here is a Dev, and even though I know a fair bit about programming it would not be a trivial task to do what is simple for you regarding checking out code injections and what they do re a security standpoint. That would probably be a long afternoon of googling for me :)
Just my view...
I have sent a message to 1Password through the official customer support channel to ask the same question posed here. I'll update once they reply.
> Thank you for taking the time to write to us here at AgileBits. The current version of the 1Password extension does not use regex to parse URLs for this exact reason. We don't autofill either, which also helps avoid issues like the one you mentioned.
Presumably that's the job of a professional security developer that might reasonably be expected to have checked their own similar product for this vulnerability...
LastPass (on Chrome) will auto-fill information on a detected site, which a malicious site can read immediately.
1Password (on Chromium nightly) requires me to hit the 1Password Mini button and select a site/account to log in with. If 1Password had a similar vulnerability, a malicious site as described would merely wind up showing me accounts for the wrong site in the dropdown. Clicking one could wind up submitting/leaking my credentials to the attacker, though.
This is actually how I use 1Password most often. Global hotkey of cmd+opt+\, type a site name, hit enter: 1Password opens the site and logs in.
See this pastebin[1] for the function I believe is determining the url of the active tab and if it has a valid hostname.
There's also this one[2] that seems to be extracting the hostname of a given url also using the URL API.
Both these pastebins contain minimized code that I've cleaned up.
0: https://developer.mozilla.org/en-US/docs/Web/API/URL
1: http://pastebin.com/tWns7XmG
2: http://pastebin.com/PXS1iqsq
It's just a tiny overhead to my workflow.
Anyway, I'm glad that LastPass has resolved this; last thing I want in the news is another big password breach.
http://ronnie.me/store-encrypted-passwords-in-an-encrypted-f...
The issue I had with 'pass' was that it leaked info via the file names, but I found a nice way around that.
* fidexURL is whatever is after :// and up until the very last @ (greediness)
* the second line fixedURL && is going to complete if fixedURL is not undefined
* url = this fixedURL, then the rest of it where @ was replaced by %40
so basically, entering http://avlidienbrunn.se/@twitter.com/@hehe.php will give
url = avlidienbrunn.se/@twitter.com/%40hehe.php
if I understand correctly. What happens after?
EDIT: it must be that the last [^/.]* before @ is taken as the domain name. But why splitting the URL before a @ sign? I'm confused
The open questions are a) how long the flaw existed prior to being fixed and b) whether attackers were able to exploit the flaw.
Update: Looks like LastPass has made a blog regarding the exploit and have stated v3 of the addon is not affected [1]. Would be nice to have further clarification of the differences between v3 and v4 with regard to this.
[1] https://blog.lastpass.com/2016/07/lastpass-security-updates....
You could even use replaceState to change it back immediately.