We log in on our end and push the session to your browser, so your browser (or that of whomever you shared the app with) never sees the password.

Doesn't this mean that if you are compromised so are all your users?

Yes, this is my next question.

Regardless of your answer I think these questions make it clear that you should definitely consider adding some more detailed explanations to your website about how exactly your product works. Especially for a security related product this is pretty important.

I say this as someone who is very interested in paying someone to solve this problem for me.

We actually have a security FAQ up here: https://www.meldium.com/security. The link is currently buried in our TOS, thanks for pointing out that we need to give it more exposure! We're definitely open to feedback as to what's not adequately covered.

It also means employees at Meldium, Heroku, and AWS (and someone who can compromise the security of any of these) has access to your passwords.

It's probably a reasonable trade for a lot of services -- I'd probably use it for an analytics dashboard, etc., but probably not for admin interfaces to do stuff to customer data (which you presumably could set up with individual user accounts and group/role management, anyway). This seems to be aimed at the ~bunch of low security passwords which are either the same across your whole business, or stored in a google docs spreadsheet now, not the most important credentials for your users.

I'm going to take that as a yes. Given all the recent hackings of Google, Apple and Zendesk, I don't think I would feel comfortable storing all my passwords unencrypted with anyone.

When you say "on our end" what do you mean exactly? You log in from your servers? So the password never actually gets sent to the employee? Just the session token?

Thanks for the clarification! Might want to add that to the website somewhere, I wasn't able to find it when looking for it there.

What if the session is bound to the IP address?

It turns out that there are very few services for which this is the case (imagine if you had to log back in to everything every time you switched wifi networks). Having said that, we have some innovative ideas for supporting the few services that have this restriction - stay tuned to http://blog.meldium.com for details.

So any service this works for (sans the manually integrated ones with service knowledge) should be highly suspect for security practices, as they are doing nothing to prevent session hijacking. You're basically offering Session Hijacking as a Service. That's rather genius.

I don't mean this to criticize you, one of the first scripts I ever sold was a better UI to a service that basically used Cross Site Request Forgery to do the work.

I submitted something very similar to YC last year with the same implementation. Works in practice but it's insecure.

The solution I'm going with now is a native client that creates the cookies locally which the browser extension then accesses. Mine's also not immediately marketed towards teams but rather individuals.

Best of luck.

To make this more clear, here is the Network tab under Developer Tools when I log into twitter:

http://cl.ly/image/3f3x3R0N0y2W

If I had actually logged in you would see my password in the space that currently says NotActuallyMyPassword.

I don't see how Meldium could prevent that.

This can be done using SSL proxying. You can run a proxy server and send the HTTP login POST request (with a fake password) through the proxy server. The proxy server can in turn replace the fake password with the actual password and forward the POST request to the end website.

It is also possible to run the proxy server on the end user machine and use a mechanism called SSL tunneling to securely replace the password. Its hard to explain it here but it can be done. The benefit of running the proxy on the end user machine is that you don't have to route your traffic through a remote proxy.

I have a system which has this thing working - will open-source it under github soon.

I doubt it's a local proxy since it's a Chrome/FF extension. Or maybe I've not kept up with the state of Chrome/FF extension development and it is completely possible to write a proxy that runs within the browser.

Extensions don't proxy anything. They do, however, have access to everything you do (type, click, etc) and everything you can see. (i.e. close enough)

According to http://news.ycombinator.com/item?id=5282855 it looks like they log in and get a session cookie for the site on their side and send that to your browser.

They could be filling in the passwords with a random string and then using the browser extension to replace it when the form is submitted.

You might be able to view the password using something like https://addons.mozilla.org/en-us/firefox/addon/tamper-data/ provided that runs after their extension.