“Sites like these give PHP a bad reputation” | Hacker News Reader

“Sites like these give PHP a bad reputation”

medium.com

51 pointsgempir73 comments

What alarms me much more than the appearance of bad code quality is the fact that we have no direct way of checking what's actually going on under the hood and what impact it has on security. If there is one axiomatic requirement for the trustworthiness of a password manager, it's that it must be open source. That way people don't have to guess at the code quality from their use of file extensions. Lots of people seem to have a huge phobia of storing their passwords in the cloud and I have the feeling that the provenly poor security of Lastpass [1] has contributed significantly to this.

<shameless plug>Padlock[2] is a penetration-tested, open source alternative that also has a (open source!) cloud storage solution[3] that you can even deploy to your own server if you don't trust the official one. All of this based on zero-knowledge (the server has no way of acquiring your master password or reading any of your clear-text data). Disclaimer: I'm the main contributor.</shameless plug>

[1]: http://www.martinvigo.com/even-the-lastpass-will-be-stolen-d... [2]: https://padlock.io [3]: https://github.com/maklesoft/padlock-cloud

That's exactly what i was trying to say with the article :)

serving .php files directly is not security issue, but as you said nobody knows what's going on under the hood.

Padlock doesn't work in Firefox?

Yeah, currently the only way to run it on desktop is through the Chrome app. A native, standalone desktop app for all major platforms will be released very soon, though.

You should avoid lastpass (and similar services) because you are giving all your credentials to a third party to be remotely stored.

Also lastpass has a history of security issues: https://en.wikipedia.org/wiki/LastPass#Security_issues

If you want to use a password manager, you should use something like pass[1].

[1]: https://www.passwordstore.org/

I don't disagree (although I prefer KeePassX), but let's be charitable:

  - What LastPass gets is ciphertext, not your unencrypted
    passwords. Important detail.
  - There are opportunities for LastPass to receive your
    master password (i.e. if you enter it on their website).

I haven't audited LastPass. After Tavis Ormandy looked at it earlier this year and published his findings, I wouldn't be surprised if the crypto was totally and hopelessly broken.

But to eschew the fact that their app does encrypt passwords before sending them to their servers isn't fair.

But nothing theoretically stop them from getting your master password.

You have to put a lot of faith in them and the question why would you always remains.

Nothing stops anyone from getting your master password, including Google, Microsoft, Apple, Firefox etc..

The thing here is motive and incentive, LastPass has not motive or incentive to handle your passwords in an unencrypted form, it has no motive or incentive to want to know your master password ever since both of those things are just a huge liability for them.

Every password manager, every browser, every OS, every hardware can be backdoored and compromised by their maintainer/manufacturer in a way nearly impossible to detect even in some cases if the source code is fully or partially available, heck how many people ever verify that the package they just grabbed via the package manager was built using an unaltered version of the source code?

To function you need to have some level of trust, you can try to add additional security measures e.g. like not storing highly sensitive passwords in a password manager but even then really depending on how you maintain those passwords you are likely to increase your risk rather than reduce it.

Spot on. And it's certainly better than what chrome does, or at least used to do. Which is no encryption at all.

The only other option is to use something like this to-do it yourself.

github.com/ezWebDevTools/ezCryptoJS

To be fair, that's true for just about any password manager unless you audit the code and use reproducible builds. It just tends to be easier to place these kind of backdoors in web apps because the code is basically re-downloaded each time ... which is worrisome given their, uhm, antiquated app "architecture."

Native apps, on the other hand, tend to have signed updates and such. I'd pick a native password manager over a web-based one any day, but the theoretical risk is still there.

Pass doesn't solve the most important issue: passwords available on all devices, most importantly mobile.

Credentials being "remotely stored" would be the case regardless of if you run any other viable storage such as Dropbox. I suppose you can remotely store on your own server, but I'm about a million times more likely to screw up than even a bad cloud company or password manager - so that's a non starter.

I'm sure there are alternatives to LastPass/1pass and similar, but storing encrypted passwords in a local file solves only a small part of the problem.

> Pass doesn't solve the most important issue: passwords available on all devices, most importantly mobile.

https://github.com/zeapo/Android-Password-Store

https://github.com/davidjb/pass-ios

Thanks, I think it's still not quite there. I either have to use Cydia(?) or have my linux machine serve(?) the passwords to my mobile device. The former isn't going to happen to most people and the latter is going to be a lot more insecure than 1Pass/Lastpass (because I sure can't set up a secure web server with certs etc).

What people need is centralized & turnkey password management. This has drawbacks , but remember: it competes on security with the only other alternative: using the same password for all sites - That's the most common password management system out there!

I keep it sync on a virtual Server with sftp, where i Upload the db, sshfs to Mount it - the Directory which contains the Database, localy on Linux, or easySSHFS on Android.

To Set this up i need for every new device around... 10 minutes

It isn't THAT hard. Im pretty sure there is a dropbox(or $urCloudProvider) App that Can sync your files too :-)

What about backup or if your encrypted password store get corrupted? It's actually not that unlikely if you open the file on many devices at the same time. Do you have history of the password store file you can go roll back to? Can you trust the VPS provider?

It's not as straightforward as you assume,now apply it to non-devs.

I've been using this on the desktop, and Password Store + OpenKeychain on Android, both are very polished apps. This setup works great with a YubiKey.

https://fossdroid.com/a/openkeychain.html https://fossdroid.com/a/password-store.html

I'm on Windows + iOS (which says a lot about how much tinkering I like to do with tech :D ).

When it comes to ease of setup and general UX polish every open solution leaves a lot to be desired. In the choice between insecure and cumbersome, insecure wins every time. Case in point: gmail is what people want in terms of usability. A more secure solution (such as any pgp solution on standalone mail client) is not really an option.

One one point: This is kind of meaningless and alarmist.

On the other: It says volumes about LastPass's code quality.

It seems to me it says more about their website quality, which is different.

The code quality of their website and the code quality of the application they sell might be two different things, but the overlap between both topics is "code quality", which is what I said.

This is still wrong, you're inferring that the website code and the application code share the same code quality. But chances are this is not true (unless there is only one dev at lastpass which would also be admin of the webserver.

> But chances are this is not true (unless there is only one dev at lastpass which would also be admin of the webserver.

This is an unknown, and we can argue until we're both blue in the face about whether or not information about app A tells you information about app B, if produced by the same company, but you don't know if the same people within said company produced both apps.

But I say that point doesn't really matter: Their quality controls are either lopsided or inadequate. Neither is a good outcome for a security company.

This says they have atleast 8 developers. https://lastpass.com/about-lastpass/

The site probably isn't the application per se, nor where the data is stored.

Wow, what an non-argument. I expected some kind of security analysis. Not a "look at them using file extensions" rant which doesn't say anything about the quality of their software at all.

How got this submission to 30 points? Voting ring?

> Not a "look at them using file extensions" rant which doesn't say anything about the quality of their software at all.

See https://news.ycombinator.com/item?id=12884523 for how the detail covered in the article could adversely affect the quality of their software and the security of their service.

I wish they had done more research in this realm, seems like they pressed "publish" far too early.

Blind passion runs stronger at late hours of the night? Europeans hate centralized, third-party, password management? So many variables that could explain it.

I've been working on a reimplementation of the LastPass command line client lately and while I was also a bit surprised when I found out that the login URL was "https://lastpass.com/login.php" I didn't really think much of it.

In the end the server side of things is really not critical since it only stores an encrypted version of the blob. Sure, it looks a bit sloppy, but if it works...

The real weakness of lastpass is and always will be the clients, in particular those browser extensions that can update in the background and are difficult to audit. But these browser extensions are also the reason I'm not using something like "pass" or even a custom GnuPG-based solution. It just works on any machine regardless of the OS without any hassle.

So far the C code of the CLI client looks decent enough. Not amazing but nothing really stands out, besides maybe the key derivation algorithm they use: they query the server for the number of rounds to use when deriving the keys and if the server replies "1" they fallback on a single round of SHA256 salted with the username. It's probably some kind of compatibility mode but that seems rather weak to me.

If somebody compromised the server they could have it tell the client that the number of rounds for any client is 1 which will cause the clients to send a "simple" SHA256 of username+password which will be a lot easier to bruteforce than the default 5000 rounds of PBKDF2.

Facebook was doing something similar (.php URL's). Should we avoid Facebook? Maybe. But for this reason? I was a PHP dev for nearly a decade and you can't possibly know the ways I hate it (unless you're a PHP dev too); but this is a very poor form of criticism.

I expected a long rant about storing all your passwords in one place. First paragraph I see reference to php, and completely sympathized with the author

And I am a LastPass customer!

(edit: clarification, I meant to portray my disdain for php. I still like (and trust) LastPass!)

Modern PHP (which LastPass almost certainly isn't using or writing) isn't really worthy of disdain.

https://github.com/paragonie/halite/blob/master/src/Symmetri...

(Disclaimer: My project.)

Just a heads up comments like these don't really say anything useful. I know you're splitting keys because that's what the function is called. What the keys are or why they're being split is what the comment should mention.

        // Split our keys
        list($encKey, $authKey) = self::splitKeys($secretKey, $salt, $config);

Also what's happening here? This could do with a comment for more junior devs. It's impossible to Google "function with a colon on the end of it in php"

   public static function decrypt( [..] ): HiddenString { [..] }

Edit: Re-phrased my wording to be a bit less boorish

> Just a heads up comments like these don't really say anything useful.

Thanks for looking through the code. I'll make the comments more meaningful on my next run through.

> Also what's happening here? This could do with a comment for more junior devs. It's impossible to Google "function with a colon on the end of it in php"

That's a PHP 7 feature called return type declarations. If it doesn't return an instance of HiddenString, PHP will throw a TypeError.

Oh no I mean if we shrink it down to the PHP it becomes public static function decrypt(): HiddenString { }

The way I worded it is implying I'm digging at you sorry. I mean the literal what does this do, I've not come across formatting things like this before

You're fine, I just didn't understand your question on the first pass.

EDIT: https://github.com/paragonie/halite/compare/v3.1.1...3b95d85...

Cheers - I need to read up and play some more with PHP 7. The joys of maintaining a 5.6 world :)

For the benefit of people not familiar with php, can someone please clarify why the author's findings reflect badly on lastpass?

They reflect poorly on the Lastpass website , not necessarily on their crypto.

Judging from the URLs, it seems that each action is handled by a different standalone script. This is very common in legacy code bases, and it typically (not always) means that:

1) all those scripts need the same bootstrapping boilerplate copy-pasted into them, which is a maintenance nightmare. Even if you simplify it to one or two lines of boilerplate that includes a central boostrap file (or use some configuration magic to automatically run an additional script before the script you requested), it's still worse than having a single centralized entry point that handles routing, auth, and so on. There's always a chance that someone forgets or botches an auth check in one of these files and it goes unnoticed.

2) you will probably be able to make an HTTP request directly to some file that was not intended as an entry point (the author mentions header.php – this is a perfect example), and then who knows what happens, because you never planned for this and your bootstrap code doesn't run and possibly variables expected by that script are not defined, or errors thrown by the script are not handled by a pretty error handler... kinda like doing an assembler jmp into the middle of another function, after any sanity checks it might have had.

3) I have been working with PHP for 8 years now, and almost inevitably, where this pattern shows up, there's most likely outdated and insecure practices like SQL queries from string concatenation (leading to SQL injection) or unescaped HTML output (leading to XSS, XSRF, or other security problems). It's basically an "easy target" sign for hackers.

Front Controller pattern [1] is a recommended alternative.

[1] https://en.wikipedia.org/wiki/Front_controller

Thank you for this! I have no experience with PHP (old or new) so I was mildly puzzled by the article. The two concerns raised seemed to be "their app layout is old school" and "they're not rewriting to pretty URLs" which both didn't really seem to justify the "avoid lastpass" title.

> 3) where there's legacy, there's most likely outdated practices like SQL queries from string concatenation or unescaped HTML output.

If you combine the article's findings with this observation, one could foresee sending a crafted /footer.php?args=SQL+Injection+goes+here type request that skips past where input is "sanitized" and results in code injection.

(Further details are NDA'd, but I've found similar issues before in production systems.)

Yep, I've seen such issues in multiple systems as well.

I have edited your reply into the article with credit. I hope you don't mind otherwise I'll remove it.

No problem :) I just edited the post to add some more security implications, because they deserve more attention.

It just shows bad (old) coding habits that might indicate the kind of code quality running lastpass

I'm so worried about sharing my passwords with ANY third party. Eventually they all get owned...

I have personally have found bliss in Password Hasher Plus (https://chrome.google.com/webstore/detail/password-hasher-pl...) (Hash it! App on android)

Basically it hashes your password together with the domain name you want to login in together with a very long private key to generate an arbitrarily long password as a final pass. The chrome extension and app provide some nice utilities to make all this pretty easy and transparent to use.

Advantages: * Only one password to remember. * Different final passwords for all services * Hashed with a unique private key * Arbitrarily generate any pasdword length you want * Passwords are not shared with anyone (automatically generated on your device) * Plus many more (that i will do a bad job describing)

Disadvantages: * More of a script approach not a full blown application (matters to some) * Different approach for desktop and mobile (extension vs app)

> I'm so worried about sharing my passwords with ANY third party. Eventually they all get owned...

1) Many password managers are designed specifically to survive the website being owned. I use LastPass and I'm not sharing my passwords with them, I'm sharing my encrypted passwords with them. It's an important consideration!

2) You don't want to trust a third party so you use a Chrome extension that is made by a third party and has permission to access any website? You are trusting a third party.

Well, I know exactly what goes in the Chrome extension (https://github.com/ericwoodruff/passwordhasherplus) or the android app (https://github.com/ginkel/hashit)

The point is that I do NOT want to store (even hashed) passwords with a third party in the hopes that they will be able to protect my passwords, when I can generate them on the spot from the device I'm using. But that's just me.

My post was just a comment on how people find third party password managers so secure. I can't be the only paranoid about this...

Obviously there's a trade-off between security and convenience here, and that's a very personal choice to everyone, so I'm not going to argue that part of things with you.

I do have to point out a couple of things though. Password managers don't store "hashed" passwords with a third party - they store encrypted ones. I also wouldn't personally use the phrase "in the hopes that they will be able to protect my passwords" - I don't rely on LastPass protecting squat. If their entire database leaked, my passwords are still safe. I think that element of the design is very important and wouldn't use a system where hope was required!

You certainly aren't the only paranoid one and lots of people on HN seem pretty wary of password managers :)

Another option is to store your full PW and/or user name. For example, add a +++ to every pw but don't store that bit in the PWM. If nothing else, it makes things that much less obvious

My key criteria for any password method is "what if everyone uses it?". If a major PWM fails, and lots of people did something like this, you can bet your boots that password crackers would give it a go and retrieve your real password.

It also has an include.php file:

https://lastpass.com/include.php

There's also a https://lastpass.com/db.php

I've been using Enpass[1] for a while now and it's great. Free desktop clients (Windows, macOS and Linux), and $10 for the mobile app. Supports a bunch of cloud services for sync.

[1] https://www.enpass.io/

I looked into enpass recently and it really looks nice. But after playing around a bit with it, I just found it too lacking in the feature department compared to KeePass [1] and it's browser extensions.

[1] http://keepass.info/

Considering the general insecurity and hackability of the internet, this is probably more of a symptom than a disease. It's the digital equivalent of the cure for cancer. 'cept the internet is printing too much money for too many peopke and no one wants to muck with that, even if it's the right thing to do.

Everything will OK. Just don't be evil ;)

Using frontend web technologies for keeping passwords safe is not the best idea. Lastpass has "restricted" password copy functionality, if passwords were shared. But it actually loads password to input field with type set to password. Open up inspect tools, change input field type to text and you have a password in plain text, you can easily copy.

I used lastpass in the beginning for a long time, and I was OK with the fact that I don't know most of my passwords.

Until the day I forgot my 'master password' (I don't know what happened... I just couldn't remember it)

And almost all my passwords were gone. Resetting everything was a real pain

That's not a problem with LastPass, it's a problem with password managers - also coincidentally a feature of them.

In case of KeePass at least, you can skip the master password and use keyfiles or HOTP such as Yubikey instead. Or, better yet, you can combine the master password with one of those.

How do you now mitigate this?

Write it down, store half of it in a safe, the other half in a compartment in your purse/wallet (which you keep on your person).

You can't.

The DB is encrypted locally using your password (wich lastpass does not have because they store only the hash)

I have much faith in Dropbox' security so I use 1password (uses Dropbox for online storage). It even works on Linux with Wine and Chrome. (except for auto-submit, but I don't use that feature anyway.)

Might it be possible to kinda fake a PWM with some sort of encryption and Git for backup / cross device access?

iCloud's Notes are not bad as a solution for simple password storage solution. No need to worry about syncing and it is secured.

Doesn't that mean Apple has access to all your passwords, though?

iCloud is encrypted, isn't it? You can also double lock your Notes with its own password.

or you just use the iCloud keychain, you know, the iCloud component designed to store passwords securely...

Yes, but keychain is not there on the online portal of iCloud, which wouldn't be helpful if you're on different OS.

Reply on news.ycombinator.com