Email & Password login security

433 views
Skip to first unread message

jose.am...@gmail.com

unread,
Feb 1, 2016, 3:00:23 PM2/1/16
to Firebase Google Group
Hi all. I'm a JS newby and I'm trying out Firebase, I'm following the documentation to implement an Email & Password authentication for a web app and just noticed that if I check the Log XMLHttpRequests option in my web console I can see the URL of the GET request and in that URL's query string my email and password are visible.

I've read anything but good things about Firebase but while learning JS I saw that I should never ever send ajax requests in which passwords are contained in the query string so I'm stuck in that dilemma.

Like I said I'm a newbie and I'm concerned about the security part which I really don't understand very well. 

Can please somebody share your thoughts about this

Jacob Wenger

unread,
Feb 1, 2016, 3:04:49 PM2/1/16
to fireba...@googlegroups.com
Hey Jose,

We hear this one in particular quite a bit and it is due to a slight misunderstanding / misconception of how HTTPS / SSL works. I won’t go into all the details, but no one, even someone monitoring network traffic has access to the unencrypted auth URLs. You can read more about this here. While you can view the URL on your local computer, no one who is packet sniffing can actually see the requests you are making. This is the beauty and simplicity of HTTPS and why we use it everywhere. You can rest assured that your username and password are being safely transmitted to our backend servers. The article mentions that the URL will be unencrypted on your local machine and in our server logs. The local machine this is a bit of a boondoggle since if someone has your computer, you are probably vulnerable to much worse problems already. As for our server logs, we take measures to scrub our logs before they are even written to so that your password is never logged in plain text.

We also often get asked why we use GET instead of POST, which would get the credentials out of the URL. The reason we use GET is twofold: (1) our login backend provides a RESTful interface for our clients. So we follow REST best practices. A login attempt is most appropriately a GET since you are getting auth credentials, instead of a POST which would be adding those credentials somewhere. (2) We support a lot of old browsers who do not support all of the new HTTP methods such as DELETE and PUT. So you may see several actions which use GET and override the method in the query string via something like _method=POST. For example, a create user call will do a GET with _method=POST. This allows this call to work on older browsers and still allows us to have a RESTful API on the backend.

Hope that helps,
Jacob

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/b890d90c-6e94-483b-88d2-294a537048d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

jose.am...@gmail.com

unread,
Feb 1, 2016, 5:43:50 PM2/1/16
to Firebase Google Group
Great! thanks a lot for the response Jacob
Reply all
Reply to author
Forward
0 new messages