I'd like to securely save a user's credentials to related web sites and automatically log them into those sites when they log onto ours. I understand there are some security implications to this, so I'd like others' feedback and see what has been successful for others in the past.
What technique have you used to auto-log the users in? I'd prefer not to have to duplicate the HTML form and submit it through javascript. This seems error-prone if the form ever changes. I tried putting the login form inside an iframe, but it seems like the owners of the site are able to block this (see attached screenshot). Do you know how they do this?
Secondly, what was your approach to save the credentials so that they were "safe".
...Peter
I would suggest using cookies to save a session certificate to the users machine. A good value for such a cookie would be;
userid, timestamp, hash(userid . timestamp . global_secret)
The value of global_secret needs to be very long (40 characters or so), to avoid people cracking the hash, as doing so would allow them to create their own credentials with other peoples user ids!
The 'other sites' would check for this cookie, calculate the hash using the cleartext values of userid, timestamp and the global_secret (which all sites know), check it against the hash supplied, if they match, then this is a valid certificate.
You would then need to check the timestamp and decide if this was a 'new' enough certificate to allow access.
This is the standard method.
Do not do this. Read the terms of services for each site (ie facebook):
https://www.facebook.com/terms.php?ref=pf
(3.2) You will not collect users' content or information, or otherwise access Facebook, using automated means (such as harvesting bots, robots, spiders, or scrapers) without our permission.
(3.5) You will not solicit login information or access an account belonging to someone else.
(4.8) You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
You put yourself and the user at risk.
These sites have an API for a reason, so I suggest you looking using those as a more "legal" approach.
So if you're trying to retrieve a facebook user's information, create an app, have them authorize your app, then retrieve the information through facebook's api (example). You can also post to their wall with this method.
https://developers.facebook.com/
https://dev.twitter.com/
https://developers.google.com/
The common method to auto login a user is to set an cookie with an random string. It have to be that the random string isn't guessable. At the server you check the cookie and if it matches then you login the user. But if your site isn't completely served with https everyone who can listen to the traffic can pretend to be the user. To increase the security a little bit you could implement that a random string is only valid for a view days and then the user has to login again and a new random string is generated. So if someone steals the cookie-id the attacker has only for a certain time access to the account.
Related
I have a webpage, let's say that the page is called: http://www.mypage.this/
In my page users can create their own HTML pages and access them through www . mypage . this / (creator's_username) / (project_name) . For instance, if my username is "USR" and my project is called "PROJECT" then the link is http://www.mypage.this/USR/PROJECT .
But there's a security problem...
I store people's login tokens as cookies. And what if some user's script has a function which reads the cookie and sends it to someone else?
They can get access to someone else's account. The token has to be saved as a cookie, because I need to verify the user in multiple pages. What should I do to prevent the user created scripts reading the tokens, yet still allow my pages to read the token?
Thank you in advance
*The tokens are of course regenerated every once in a while
To clear misunderstanding, I am NOT storing passwords in the user's side. I am storing a login cookie - a randomly generated string, re-generated on every login. And I store that on the user's side.
If you have to verify users in multiple pages, you should store login information in the session, not in the cookies. This way everything stays on your server, and only you can access it.
Cookies are made so that you can store information even when the user disconnect, leave the browser or anything else.
Storing login information in cookies is generally a bad idea, as it's not really secure.
Oooh. You really don't want your users to be able to create pages that run scripts in other browsers. That creates a risk of cross site scripting vulnerabilities (like that one you've mentioned here). Your safest bet is to start with blocking all SCRIPT tags. Then there are probably other things to block as well. This is something worth spending time reading about:
https://en.wikipedia.org/wiki/Cross-site_scripting
https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS)
I am using ember to write a web ui for a site that requires user to log in. Suppose the browser has stored some cookie from last login of a user. Now the user visits the site again. So, is it a secure and common way for ember to log the user in automatically based on the cookie from the last visit? If so, what are the common ways to implement this? (I can't find anything from Google.) Furthermore, how do I create the cookie upon login? Is it a common way to just put a user id, password hash, and expiration in the cookie?
Additionally, any references related to this subject are greatly appreciated.
Edit 1
In light of Vohuman's answer, I think I can make my question a little more specific. Basically, what I want to know is a common and secure implementation to keep a user logged in, even when they close and reopen the browser. Namely, the life time is beyond the session scope. Take linkedin for example. If you are logged in and exit the browser. Then next time you revisit linkedin, you are still logged in automatically. Right now, what I can picture is a solution like the following.
When you first log in to the site, the server will return a cookie which includes an authentication hash token. Then next time when you revisit the site, the server will receive the hash token and thus authenticate your session.
So, is above flow basically what people usually do to keep a user logged in? If so, is the JSON Web Token (JWT) basically one way to construct the hash token I mentioned above? Additionally, assuming the connection is HTTPS, this approach seems secure to me. Is it not?
Edit 2
This article gives an interesting discussion regarding where to store the access token.
is it a secure and common way for ember to log the user in automatically based on the cookie from the last visit?
Yes and no. Security is a complex topic. Usually session cookies are used for authorizing users. This is actually the most used method of keeping the users logged in. If the user can't keep his credentials secure then any layers of security can be vulnerable.
For Single-page applications usually access tokens are used instead of cookies and sessions. The client sends the user credentials and server returns an access token. The token is encrypted and expirable and can be stored in localStorage or sessionStorage. Using JSON Web Tokens (JWT) standard is a popular method for implementing user authentication and authorization in web services. As an example, the Facebook Open Graph API uses access tokens.
JSON Web Token (JWT) is a compact, URL-safe means of representing
claims to be transferred between two parties. The claims in a JWT
are encoded as a JSON object that is used as the payload of a JSON
Web Signature (JWS) structure or as the plaintext of a JSON Web
Encryption (JWE) structure, enabling the claims to be digitally
signed or integrity protected with a Message Authentication Code
(MAC) and/or encrypted.
edit:
So, is above flow basically what people usually do to keep a user logged in?
For traditional websites, yes.
The whole point of using access tokens is keeping the web service/API stateless. This means that server doesn't have to store any cookies/sessions for authenticating and authorizing users. The stateless is one of the key factors of implementing web services that follow the REST paradigm. It's client that has to store the token and send it to the server (via the Authorization header or query parameters). The server doesn't store the token. Of course, you can store the tokens on the server if you want to add another layer of security, but it's not so common and not necessary. Storing the tokens on the server can also make your application vulnerable to database attacks and is not recommended.
If you want to make the process more secure you can decrease the validity time of access tokens (1 hour, 1 day or 1 week, it's up to you).
As for localStorage, is it secure?
localStorage data are stored separately for each origin (domain). A malicious user can only read the data if he/she has access to the user browser. You should make sure that your app doesn't have any XSS vulnerabilities so malicious users can't inject any scripts to your application. This is actually a different topic.
Is it possible to access cookies from an email? My fear is that one can for instance steal facebook login cookies simply by sending an email.
I know it's possible to redirect a user to an url without him to be aware of it. For instance, I used to display a 1x1 gif to redirect the user to a url (I used that to make email opening stats). What if on the target url I create a malicious js script: will I be able to access the user's cookies?
Or to put it differently, if there is a link in the email and the user clicks the link, is the target website able to access user's cookies?
I read this; does anyone have more details on the subject?
#user3345621
Thanks for your answer, it seems correct to me.
But to take on the facebook example again, I have a couple more questions:
I may be wrong, but I think the cookie encryption does not help in this case.
The cookie encryption will help to hide the password in case for instance I access
your local machine and look in the cookies directly.
However, if I steel the encrypted cookie, I will be able to use them,
and let facebook do the uncryption work.
So in other words, I think it does not matter whether or not cookies are encrypted,
as long as the application (facebook in this example) will decode them for you.
Now, same remark about the fact that the cookie is recreated.
I think this is a direct consequence of using session_regenerate_id function.
But anyway, my understanding (which may be wrong) is that even if the cookie is recreated,
if the hacker send you a malicious email, he will get the newest version of the cookies
anyway since in the technique I'm describing, you're redirected to a malicious website,
so that website, when opening would have access to the current cookies (if possible).
?
I might be incorrect, since I'm fairly new to application security.
Here goes my best shot, concerning cookies now:
Cookies are domain specific (FACT), when you have a facebook cookie storing your user ID and your email (perhaps?) only the facebook domain has access to that cookie. Also, in most cases, the information in your cookie, especially in enterprise systems such as facebook, is encrypted, in other cases a hash is used to mask the information (Sort of fact).
So let's take facebook as an example, since they use a strong encryption format (FACT). If for instance you were able to get hold of a users facebook cookie, you would need to de-crypt the information to start off with, for it to be of any use to you. By that time a new cookie would have been generated (darn facebook adddicts).
Onto the security issue, if by some means you were able to get hold of a users cookie that does NOT belong to your domain, it would be a hack (do'h!), and you would need to check for any browser (Yes you should be exploiting the browser), that has such an exploit, or look for one yourself..
So here they are:
Browser Exploit, hack a specific browser.
De-crypt (or de-hash) the cookie, if it's encrypted.
And do this all be for the cookie has expired.
And the world is yours.
I tried to send me an email with the following image:
<img src="http://localwebsite/js.php" />
On my local machine, I created a page at this url:
http://localwebsite/js.php
Which would alert("something") using javascript.
Sending the email to myself,
I expected that the mail client would open a web browser page and open the js popup,
but that's not the case at all.
What happened is that since it's not really an image,
my mail client (using mail on mac) did display a blue square exclamation mark,
indicating that he could not display that image.
Even if I click on "load images".
Then nothing more happens:
I presume the mail client goes to the url and tries to display the expected image in the message,
but since there is no image, nothing changes.
The url wasn't open in the browser at all, everything was done in the background.
Reading more about javascript in emails, it seems that generally, javascript is not interpreted at all
in emails.
I tested that too: sending an email containing:
<script type="application/javascript">alert("pou")</script>
Mail (mac) does not execute the script.
So to answer the question,
I believe that the only thing a hacker can do with mail is:
sending a link, then if you click on that link, anything can happen
create an image that he can use to track whether or not you've opened the mail
So if you're cautious enough, mail are'nt a big threat.
I was paranoid…
I need to somehow detect the IP address of some of my website visitors and let them access the website without loggin in. Currently the content of the website is password protected and the visitors should log in in order to get access to the content. But I was wondering if there is a way to let some of our customers to get access without logging in by detecting their IP address.
Is this possible? If yes, what's the best solution?
Thanks
First off; this shouldn't be a Javascript question. You can't write site security in Javascript, because it runs on the client's computer, and you can't trust that computer. They could just open devtools and replace "if (loginOk())" with "if (true)"
Usually, this is accomplished not via IP address (which is pretty easily spoofed) but with some sort of randomized cryptographic hash given to them as a cookie. I can summarize it for you in a short way, but you'll want to look up the idea of "oauth tokens".
User logs in using their username and password
In the Response to their login action, the server sets cookie 'mysite_login_token' to a highly randomized string based off of their user information and the current date, ie 'noonewilleverguessthisstringofletters' (well, no, not that exactly - like I said, read more specialized articles on the subject).
In all subsequent requests to sensitive information, the server checks the sent value of 'mysite_login_token', and makes sure it matches the stored value for that username.
If the user logs off, then the server deletes its copy of that token so it can't be used again.
you can't in pure javascript; you can use a server side service using .net or php and use XHR to fetch the result
The IP address could be useful for making an initial guess at who might be on your system if no login or cookie is presented. The IP can be used to obtain their approximate location or for logging the activity of anonymous users. The cookie is certainly a better way to re-identify a client machine than an IP, because dynamic IP's change periodically. Still identifying a machine is not the same as identifying a particular user. The IP or cookie for a machine at a public library won't identify a particular user. See: geolocation website
I wrote a simple demo html (SSL enabled) forms to access some university services thru it. It requires the user to login with his university ID first .
My question is , how to encrypt the logins data even from me the owner of this page ? Is it possible ? so that the user can confidently use this.
You could use HTTP Digest Authentication which does challenge-response authentication and always sends password hashed.
The problem with Digest is that UI for it is ugly and logging out is left up to the browser (you can't have a reliable logout link).
Alternatively you could implement your own challenge-response mechanism in JavaScript, e.g. http://code.google.com/p/crypto-js/
but it's rather pointless, because the user doesn't have any guarantee that you're doing it, and that you won't replace the secure script with an insecure one in the future. As the site owner (or somebody that hacks your site) you could change the script and "steal" passwords at any time.
SSL is good. That's the best real security you can do client-side.
You can ensure that you're storing passwords securely on server-side — hash it with a slow hash such as bcrypt (not md5/sha1) and use unique salt for every password.