There's a level of irony in complaining about LastPass's security, followed by suggestion people run their passwords through random third-party software that you wrote. Even if your code isn't malicious (which I believe), it opens up so many potential attack vectors.

For anyone reading this, please use the official 1Password import functionality, not this: https://support.1password.com/import-lastpass/

There was no 1Password to LastPass importer at the time I wrote that (believe me, I looked because I have better things to do than write apps to benefit a commercial entity like agilebits otherwise), and of course the code is published on GitHub and released under the MIT license. It's very short and simple and rather easy to review. It's also a .NET executable, which is ridiculously easy to reverse-compile back to C# (not just assembly) so you can even check that I'm distributing an exe that does the same thing as the code I published.

EDIT

I just revisited that link I shared, and I have to say, it takes some real chutzpah to turn around and accusing me of advising insecure practice when the link I shared literally talks about just that:

Due to the nature of this application, 𝘄𝗲 𝘀𝘁𝗿𝗼𝗻𝗴𝗹𝘆 𝘂𝗿𝗴𝗲 𝗲𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝘁𝗼 𝗱𝗼𝘄𝗻𝗹𝗼𝗮𝗱 𝘁𝗵𝗲 𝘀𝗼𝘂𝗿𝗰𝗲 𝗰𝗼𝗱𝗲, review it quickly, and compile it yourself to use this tool. However, we do recognize that this may be beyond the means of all security-minded folk out there looking to make the switch, so we are providing signed binaries available for download. If you do opt to use the binary download, make sure to validate the authenticode signature like so: ...

I am extremely grateful to ComputerGuru and others who freely share code and binaries they used to scratch a specific itch like this. As for security, I'd never dream of running anything like this outside of an isolated, offline system and would destroy the instance immediately afterwards.

> There was no 1Password to LastPass importer at the time I wrote that

The details were hazy, but in 2016, there was a way to export your passwords from LastPass and import them into 1Password, though I don't think there was a way to do so on windows (which I believe is what your importer addresses).

After LastPass vulnerability in July 2016, I switched to 1Password.

Password managers generally use CSV, avoiding vendor lock-in. However, back when Lastpass doubled their subscription cost (yes, doubled, literally) I switched to Bitwarden. At that point, there was some issue with exporting passwords with a certain character (IIRC it was ; or #). I ended up changing the few passwords which quit working.

As for OP, my take is you clicked a bad link triggering a zero day vulnerability in your browser, or perhaps you logged in on Lastpass via a VPN or Tor? Its pure speculation though.

There is, I just did it recently. It's an unncrypted copy paste dump from lastpass into 1password

This was in reference to the OP not having an option in 2017 to import to 1pass.

If I recall, I had to sign up for LastPass premium to pull my passwords to my phone, and then use keychain to import them to 1pass.

I don't think that solution would work for Windows users back in 2016.

There was a 1password to lastpass importer at that time, I know because I used it

Just because you put a warning label on a bad practice doesn't mean it's a good practice.

Pumping your passwords through some random code on Github that has a "be smart" label doesn't make it a good idea.

Would be so easy to imitate you, reupload the code with an exploit. For giggles, if I was making this into a hijack I'd leave all your warnings in and even make them bigger and more obvious, confident in the knowledge that 99%+ of my stolen users wouldn't read the code or would just download the binaries sight unseen.

1) Clone random git repo on Kali, related to Kali usage.

2) Don't read the code.

3) ???

4) Forever don't know what or when it happened.

> Just because you put a warning label on a bad practice doesn't mean it's a good practice.

That is such a salient point, generally.

Funny how common it is though

Well, why shouldn't people who already use insecure software with vulnerabilities (LastPass) without the possibility to even audit the code also run some code written by other people they don't know?

BREAKING: There is no perfect security.

>Would be so easy to imitate you, reupload the code with an exploit.

Put your keyboard where your fingers are: do it by tomorrow morning and post here when you're done.

And there ya go.

Clearly we both agree it's an insecure practice, since you felt it needed a warning.

Now that you know there's an official LastPass importer for 1Password, I'm curious why you're defending your version rather than updating your blog post, unlinking your original HN comment and deprecating the GitHub repo.

I believe you're genuine and just trying to help. If there's an attack, it wouldn't be you doing it – it'd be someone else replacing the binaries on an old 2017 post without you noticing. WordPress is just as insecure as phpBB. Like the other commenter said, "Just because you put a warning label on a bad practice doesn't mean it's a good practice."

cut them a break. no body's gonna to update a 2017 blog post irl, and last I checked a majority of the bloggers just use Wordpress, not exactly their problem.

I agree that's the right response, maybe just give them some time to consider it. It can be tough to give up something you worked on.

There's a level of irony in complaining about malicious code, and still recommending a closed source password manager.

I can't parse this. Is your point that "closed source" is a synonym for "insecure"?

Closed source is a synonym for insecure if you accept secure means no blackbox processes.

Do you think bank ATM software/hardware, plus online banking and components should be open sourced?

Dingding Exactly!

Sorry, what do you mean by "to log in to their bbuletin or whatever php forum"?

According to LastPass, they don't have access to the master password // presumably it's not stored on their side. Is that accurate..?

Thanks

After a bit of searching, I wasn't able to find any PHP forum software that LastPass lets you log in to. I could only find one official-seeming forum, and it uses a different login. So, I think this is FUD... I don't use LastPass, but accusing them of something like this (and using the phrase "or whatever") is pretty serious without proof.

They appear to have sunset their phpBB instance. It was the main hub and support portal on their website with up to thousands of active visitors at any given time. You can see it archived here:

https://web.archive.org/web/20150629081250/https://forums.la...

Here's the archived phpBB login page. It asks for your LastPass login and password (not your forum account, your actual LastPass login and actual LastPass master password):

https://web.archive.org/web/20150717071236/https://lastpass....

Here's a past HN discussion from the time with some guesses at how such a phpBB login using the master password could, theoretically, be implemented without knowledge of the password. Note that this doesn't imply it's possible to implement it in a way that would be resistant to their web server (running phpBB!!!!) being compromised: https://news.ycombinator.com/item?id=16016171

Unless I’m misremembering, the login to their general system was done by never sending the password over the wire. Instead they used js to do some sort of hashing type system locally.

But during the heartbleed attack when their systems were shown to be vulnerable, that was one of their arguments as to why it wasn’t so bad.

They pretty heavily fumbled exactly this heartbleed response too. They claimed they "weren't vulnerable" because of this setup but they clearly were. If you exfiltrated an SSL key, which heartbleed allowed, you can serve whatever JS (including JS that just explicitly exfiltrated your passphrase) you wanted to end users.

LastPass is full of clowns. There's already two examples of their cavalier approach to what should be simple security in this thread and I'm pretty sure there are more.

> Instead they used js to do some sort of hashing type system locally.

Just the other day a co-worker brought up this idea as an offhand remark. After bouncing it off those present, it took him all of twenty seconds to see why it might do harm and will do little good.

You'd think a password manager would employ some security minded people who could shoot down ideas that bad immediately.

What were the counterpoints?

A weakness in your clientside hashing will make your site weaker to brute-force attacks, since it will reduce the number of hashes (or passwords) an attacker has to try (collisions in client-side hashes will too, but very negligibly for a good hash function). It's also impossible to recover from without relying on another form of authentication to re-establish trust. For many sites this means downgrading to single-factor.

Any hash upgrade mechanism can be abused by a (possibly MITM) attacker to change a user's password while leaving you and the user none the wiser that specifically this occurred. If you need to lock someone out while their phone is beeping at them over their bank account being emptied, while not even making it look like their password was changed, that sounds like a fun way.

Lastly it's virtually the same as plaintext, since any salt will be known by even just a passive attacker. A true MITM won't even have to brute-force the hash.

Conclusion: Might do harm, will do little good.

Thanks, that's pretty damning.

I don't think this is accurate. It appears that the phpBB instance performs a redirect to a SAML login, meaning the login page where you're being asked for your master password is the regular login page.

Now, the fact that they have a web-based vault access requiring entry of your master password? Pretty bad, considering you can't disable it, and it's automatically activated even when just using the browser extension (at least as of a few years back, when I asked them to fix that.)

I don’t use Lastpass, but if what you are saying is correct, they could not have sent the OP an e-mail (assuming it’s legit) informing them of the attempt to sign in using the master pass from Brazil, right?

Cryptography means lastpass doesn't need the master password to verify the password.

If you have the hash and algorithm used to generate it of a human generated password you can in the vast majority of cases get the password.

It’s a combination of people being very bad at generating, remembering, and entering passwords plus generally being unwilling to wait minutes or even seconds to generate the hash on their local computer.

> If you have the hash and algorithm used to generate it of a human generated password you can in the vast majority of cases get the password.

I mean, technically this is true, but it's also true if you have the ciphertext of the stored-password database, which is sort of LastPass's entire job. ;)

The only thing that might make it harder to brute force the master password with the latter than with a hashed password database is if the key derivation algorithm differs.

But I think your blanket statement is sort of misleading. In principle, if you trust someone with your encrypted password storage database, you should trust them with a hash of your master password; both serve as brute forcing oracles.

MD5 is long considered a broken, weak hash algorithm. Here is the MD5 hash of a password:

d9afca35a87a2af4168500640fcf2370

Password is 16 characters long, all lower case, no numbers, no special symbols.

Please tell me the password.

What percentage of people do you think actually use 16 character passwords?

Probably pretty low.

I use 64 character passwords, or if there is a length limit, always the longest possible. That’s the beauty of using a password manager :)

Do you use 64 character master password?

One advantage about having memorized a bunch of poetry back in the day is I have a lot of secure long passphrases to hand

Aesop, my author, makes mention of two mice and they were sisters dear 1234567890123456789012345678901234567890123456789012345678901234567890

70 and little effort

I consider mine pretty long, and it's right around 30 characters.

56 billion md5 hashes per second for $1.80 per hour at OVH. (single Nvidia Tesla v100 GPU)

Still a no-go for plain old brute forcing all a-z combinations. But, if your password is some combination of actual words, common keyboard sequences, or anything else in a password dictionary, it's cracked pretty quick/cheap.

The best I could find is this

https://stackoverflow.com/questions/10041298/how-to-recover-...

But can you show me the way how you'd go on about this? Really curious.

You can't. That's the point of the post. There is no known feasible pre-image attack on MD5.

You don't need access to a password to check it, just the hash (then they hash what you enter and compare the hash to the one they have). So both "They use it to log in to their whatever" and "They don't have access to it" can be correct.

If there’s a breached phpbb instance, the attacker can modify login.php to log plaintext credentials.

Is there an official counter for phpBB RCEs/vulnerabilities that revealed user passwords? This has been going on for decades now. It's getting ridiculous.

Welcome to frameworkless PHP where code & user files are stored in the same root and any PHP file requested by a web client is executed by the server.

In most proper frameworks, including PHP ones, the only thing responding to web requests is an entrypoint file (that gets passed the request metadata including URL) and the framework takes it from there. This means that with proper configuration, even requesting a malicious PHP file shouldn't actually execute it and instead hit the framework which will promptly respond with a 404 (of course, with PHP the danger is that in case of misconfiguration the server may still prioritize an exact path match and execute the file rather than defaulting to executing the framework's entrypoint, where as other languages typically don't rely on the webserver to execute the files and couldn't run a malicious file even if they tried).

But these stupid legacy applications are still around and haven't been updated to fix this design flaw, so any flaw in sanitizing uploaded files turns into a persistent RCE. I'm sure some people will pitch in and say this isn't a design flaw and you're using it wrong, and while I agree that it can probably be made secure with enough effort, why leave such a loaded footgun around when this is essentially a solved problem in all other languages?

In other languages a malicious file being uploaded to the web root will at best result in a stored XSS which can be further mitigated by having your file uploads on a separate domain, but in PHP it's fatal.

> the server may still prioritize an exact path match and execute the file rather than defaulting to executing the framework's entrypoint

This is properly solved by frameworks having this entrypoint be in a ‘public’ folder and that also being the webroot, so only index.php and nothing else is available for a direct match (unless /../ in the url works, which would be a huge security hole).

we miss cgi-bin/

good mention. an rtfm for everyone else.

There is such a counter, CVE databases.

If you would actually take a look, you would realize you are spreading FUD.

phpBB has been rewritten from scratch around 2008 with phpBB3 and hasn't had a single severe vulnerability since. That's 13 years.

Sure. But CVEs don't enumerate RCEs/vulnerabilities that reveal user passwords - they care about a superset of all of that. And when you look at the common vulnerabilities in phpBB3, "phpBB3 hasn't had a single severe vulnerability" seems like very selective language.

I am merely giving my unprofessional opinion that phpBB(1+) has only caused harm. A significant portion of leaks seem to be attributed to it. They really could have done better, and their reputation is forever dead.

To make clear: I am sure that the current version of phpBB works just fine and isn't as disease ridden as we all know it to be. However, the fact that all of these issues have existed for so long means that perhaps we need to take a look at the software as a product and determine that its performance has not been good enough, and to expect similar performance in the future.