3 ms·

How does it actually work? How can it fill out a password form field for me, but make it so I can't find out the password? Can't I just sniff what my browser s

by harryh 14y ago

How does it actually work? How can it fill out a password form field for me, but make it so I can't find out the password? Can't I just sniff what my browser sends to the server? I'm suspicious. This is a real problem though. PS: You might want to reconsider that name. Meldium, to me at least, just looks like someone typoed when trying to type Medium.

harryh 14y ago
To make this more clear, here is the Network tab under Developer Tools when I log into twitter: http://cl.ly/image/3f3x3R0N0y2W 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.
- soumyadeb 14y ago
  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.
  - stanleydrew 14y ago
    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.
    - Hello71 14y ago
      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)
- pixelcort 14y ago
  According to http://news.ycombinator.com/item?id=5282855 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.
potshot 14y ago
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.
- harryh 14y ago
  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?
- krallin 14y ago
  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.
- signed0 14y ago
  Doesn't this mean that if you are compromised so are all your users?
  - harryh 14y ago
    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.
    - potshot 14y ago
      We actually have a security FAQ up here: https://www.meldium.com/security 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.
  - signed0 14y ago
    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.
signed0 14y ago
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/ https://addons.mozilla.org/en-us/firefox/addon/tamper-data/ provided that runs after their extension.

by harryh 14y ago

harryh 14y ago

To make this more clear, here is the Network tab under Developer Tools when I log into twitter: http://cl.ly/image/3f3x3R0N0y2W 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.

soumyadeb 14y ago
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.
- stanleydrew 14y ago
  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.
  - Hello71 14y ago
    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)
pixelcort 14y ago
According to http://news.ycombinator.com/item?id=5282855 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.

potshot 14y ago

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.

harryh 14y ago
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?
krallin 14y ago
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.
signed0 14y ago
Doesn't this mean that if you are compromised so are all your users?
- harryh 14y ago
  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.
  - potshot 14y ago
    We actually have a security FAQ up here: https://www.meldium.com/security 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.
- signed0 14y ago
  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.

signed0 14y ago

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/ https://addons.mozilla.org/en-us/firefox/addon/tamper-data/ provided that runs after their extension.