I want to password protect a web page. I'm wondering if anyone would critique my approach.
An anonymous user would go to the page and a modal would open up asking the user to enter a password. I would of course not display any content at the back in case anyone decides to be clever and display:none; the modal.
Once the user enters the password, I would redirect and save a randomly generated token as a cookie and check for that so that user wouldn't have to keep entering the password.
Just wondering if there are any security issues here aside from a personal physically accessing the computer and also if there would be any improvements that could be made.
I know I'm still being a little vague on some details, so let me know if there's anything important that I left out in regards to exact implementation.
Even though what you describe might work, in general it's a bad idea to implement your own security. Even if you use https to prevent sniffing of the token, someone might find that your random numbers are not really random and be able to guess the next number.
You will be better off using one of the security feature that comes with the framework in which you are building your application. Most frameworks support something like forms-based authentication. It might even support claims-based authN with security tokens.
As you're not mentioning what framework you're using, I can't recommend anything.
It's a horrible idea. The password as a cookie would be transmitted in the clear in every HTTP request. There are plenty of examples of how to do this correctly. I am not going to elaborate because this question is very likely going to be flagged. NEVER save a password anywhere. The first thing to do with a submitted password is compute a hash value. The hash becomes the password.
Related
Hello fellow developers
I have obviously under estimated a thing when developing my first complex web site, where user creation and login is required.
It appears that cookies can be edited and modified by the user logged in, by using some developer tools i.e. in Google Chrome. That, I never gave a thought.
So, here is my issue.
When the user is logged in, I store the user name in a cookie.
If username-cookie is not blank, and I can find a user file with that name, the user is logged in, per se. Otherwise, no user is logged in.
When the user logs out, I simply expires the cookie, which works fine.
Now, the problem is, that a user obviously can edit the content of a cookie, outside the web application, or with javascript.
What would be the correct approach here to ensure, that the username cookie is not compromised in any way, other by my web application?
Making them read-only is not possible, I assume. Encrypting the cookie and then decrypting might work, I guess. Then, the cookie would be nonsense to the user, and if modified, result in a logout, as no valid username can be found upon decrypting the edited cookie.
I have stalked Googles cookies, and it appears that there are a lot of xxID cookies, which contains garbage. Does that mean, that encrypting/decrypting is the only way to make it work? I also considered some kind of login-ticket, but that would require a table lookup every time a user interacts with my web page.
Can anyone give me a hint as to what would be the correct approach?
Thanks in advance
Best regards,
Karsten Heitmann
You should look up session management for the language you are using.
The traditional approach is that when a user logs on, your application generates a long, cryptographically random token called the "session id" and sets that into a cookie. It stores data like who is logged in on the server side identified by the random value, so when a logged on user comes back, the browser sends the cookie with the random session id and the application can look up session data on the server side. This way an attacker has no way to guess a valid session id for a logged on user, assuming the session id is cryptographically random and long enough (which more precisely means it has enough entropy). Logging out means deleting the session data on the server side, and also removing the cookie, but that is not the most important part - the session will be invalid anyway.
Note that you should not code this yourself. You did not mention the language and environment you are developing in, but session management is rather tricky business if you want to secure it, and it is already provided by most languages / frameworks.
Just for curiosity, the encryption approach you mention is by the way a valid one. Some frameworks actually do that, but you should not attempt to code that either, because it is very easy to get it wrong, lots of things need to be taken care of to make it secure enough. Unfortunately an answer here is not the right format to go into details I'm afraid.
Btw you mention looking at Google. They use their own single sign-on solution, it is very complex compared to simple session management, so it's probably not the best example for you to look at. Find simple websites, most of those work the traditional way.
I have received a request, and I cannot find a secure way to implement it. If you know a secure way to do this, please let me know.
I'm developing www.abcd.com with ASP.NET MVC. The client already has a xyz.abcd.com domain with an authentication system. They want me to create a page on www.abcd.com, where user can enter a username and password, then by hitting the login button, I open a xyz.abcd.com/login page in a new window and populate username and password with what the user has typed in my page.
I cannot find a way to do it from server-side.
If I want to do it on the client-side, I think it's against "same-origin policy" and also, I'm not sure running both www.abcd.com and xyz.abcd.com on SSL is secure enough to do such a thing.
Could you please let me know, if there is a secure solution?
I think the subdomain application (on xyz.abcd.com) should have explicit support for this to be possible, like for example populating its fields from request parameters or maybe a cookie (though I would rather not do that, especially not in case of the password).
If the subdomain application does not support this, I think you can't populate its fields, not even from abcd.com, let alone from another domain.
Please note that it would be a vulnerability (and against the best practice of course) to auto-populate the password field, which should even be set autocomplete="off" to prevent even the browser itself from filling it in.
Without knowing the context to these applications, I suspect you need some kind of a single sign-on to achieve your real goal.
I have a simple site with a sign-up form. Currently the user can complement their registration with (non-critical, "low security") information not available at the time of the sign-up, through a personal (secret) URL.
I.e., once they click submit, they get a message like:
Thanks for signing up. You can complement your registration by adding information through this personal URL:
http://www.example.com/extra_info/cwm8iue2gi
Now, my client asks me to extend the application to allow users to change their registration completely, including more sensitive information such as billing address etc.
My question: Are there any security issues with having a secret URL instead of a full username / password system?
The only concern I can come up with is that URLs are stored in the browser history. This doesn't worry me much though. Am I missing something?
It's not the end of the world if someone changes some other users registration info. (It would just involve some extra manual labor.) I will not go through the extent of setting up https for this application.
This approach is not appropriate for sensitive information because it's part of the HTTP request URL, which is not encrypted and shows up in many places such as proxy and other server logs. Even using HTTPS, you can't encrypt this part of the payload, so it's not an appropriate way to pass the token.
BTW, another problem with this scheme is if you send the URL to the user via email. That opens up several more avenues for attack.
A better scheme would require some small secret that is not in the email. But it can be challenging to decide what that secret should be. Usually the answer is: password.
Another potential problem lies with the users themselves. Most folks realize that a password is something they should try to protect. However, how many users are likely to recognize that they ought to be making some sort of effort to protect your secret URL?
The problem here is that although it is hard to guess the URL for any specific user, given enough users it becomes relatively easy to guess a correct url for SOME user.
This would be a classic example of a birthday attack.
ETA: Missed the part about the size of the secret, so this doesn't really apply in your case, but will leave the answer here since it might apply in the more general case.
can complement their registration with (non-critical, "low security") information
It's hard to imagine what user-supplied information really is "low-security"; even if you are asking for a password and a username from your customers you are potenitally violating a duty of care to your customers; a large propertion of users will use the same username/password on multiple sites. Any information about your users and potentially a lot of information about transactions can be used by a third party to compromise the identity of that user.
Any information about the user should be supplied in an enctypted format (e.g. via https). And you should take appropriate measures to protect the data you store (e.g. hashing passwords).
Your idea of using a secret URL, means that only you, the user, anyone on the same network as the user, in the vicinity of a user on wifi, connected to any network between you and the user, or whom has access to the users hardware will know the URL. Of course that's not considering the possibility of someone trying a brute force attack against the URLs.
C.
The secret URL means nothing if you're not using SSL. If you're still having the end-user transmit their identifying information across the Internet in the clear, then it doesn't matter how you're letting them in: They are still exposed.
The "secret URL" is often referred to as security by obscurity. The issue is that it is super simple to write a script that will attempt various combinations of letters, symbols, and numbers to brute force hack this scheme.
So if any sensitive information is stored you should definitely use at least a username and password to secure it.
I have a website registration page, and I'm trying to compile a list of what I need to do to protect it. If you know of an attack, please name it, and briefly describe it preferably with a brief description of its solution. All helpful answers/comments receive an up vote.
Here's what I have in mind so far: (and adding what others are suggesting. Phew, adding other input turned out to be lots of work, but please keep them coming, I'll continue adding here)
SQL injections: from user input date. Solution: prepared statements.
[AviD] "Stored Procedures also provide additional benefits (above prepared statements), such as the ability of least privilege on the DB"
Good point, please explain. I thought stored procedures were THE SAME as prepared statements. What I mean those statements were you bindParam the variables. Are they different?
Not hashing the password before entering into db. Solution: hash passwords.
[AviD] "re Hashing, the password needs a salt (random value added to the password before hashing), to prevent Rainbow Table attacks and same-password attacks."
"the salt used should be different for each user."
Good point, I have a question about this: I know salt should be random but also unique. How do we establish the unique part to counter against the same-password attack? I've been reading on this, but didn't get a clear answer on it yet.
[Inshallah] "if you use a long salt, like 16 chars for SHA-256 ($5$) then you don't really need to verify its uniqueness"
[Inshallah] "Actually, I think it doesn't really matter whether or not there are some conflicts. The salt is only for prevention of table lookups, so even a 2 char salt will be a (small) gain, even if there are conflicts. We are not talking about a cryptographic nonce here that absolutely mustn't repeat. But I'm not a cryptanalyst"
Good point, but does anyone have disclaimers on this point?
Dos attacks?! (I'm guessing this applies to registration forms too)
[Pascal Thivent] "Use HTTPs when submitting sensible data like a password." "for man-in-the-middle attacks, provided that adequate cipher suites are used "
What are the "adequate cipher suites" being referred to here?
[Koosha] "Use HTTPs or encrypt passwords before submition with MD5 and Javascript in clientside."
I don't agree to MD5 and don't like encrypting on client-side, makes no sense at all to me. but other input welcome.
[Dan Atkinson] Exclude certain usernames to prevent clashes with existing pages that have the same name (see original post for full answer and explanation)
[Koosha] "limit allowed characters for username.for example alphabet and numbers, dash(-) and dot(.)"
Please explain exactly why?
[Stu42] "Use Captcha so that a bot cannot automatically create multiple accounts"
[AviD] "There are better solutions than captcha, but for a low-value site it can be good enough."
#AviD, please mention an example?
[rasputin] "use e-mail verification"
[Andrew and epochwolf] xss attacks
Although I don't agree with Andrew and epochwolf to simply filter < and > or to convert < to &tl; and > to >. Most opinions suggest a library like HTMLpurifier. Any input on this?
Use HTTPS, i.e. a combination of HTTP and SSL to provide encryption and secure identification of the server when submitting sensitive data like a password. The main idea of HTTPS is to create a secure channel over an insecure network. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks, provided that adequate cipher suites are used and that the server certificate is verified and trusted.
Use recaptcha or asirra to avoid automatic submission. That should stop the bots and script kiddies.
To stop hordes of humans from submitting spam (via mechanical turk or anything like that), log each attempt in memcached and as soon as you reach a maximum submissions from the same IP in a given period of time, block that IP for a few minutes (or hours, days, whatever...).
You should use e-mail verification
and addition to Koosha's answer :
if you let usernames including such chars "#&?/" and create user pages like this site.com/user?me&you/ it may be serious problem in browsers. Please think it in url address bar of browsers.
I guess you should use a salt when hashing the passwords.
Use Captcha so that a bot cannot automatically create multiple accounts
If the routes on your website are set in a particular way (ie, going by the username, rather than their id), then having a username like 'admin' could cause problems. You should probably have an exclude list of possible usernames.
This caused problems in the past with MySpace, and people having usernames like login, and then decorating their page with a phishing form.
Edit:
As has been mentioned in the comments by AviD and Peter Boughton, it is also a way of misleading users. Let's say that a user has the username 'admin'. Then, in their user information page (assuming that they each get one that is available to all, like SO), they have some link in their about section that says like
For more information, visit our dev
blog at mysite.cn/loginpage
Someone maybe sees, 'mysite' in the url, but doesn't really look at the TLD, which would be China (sorry China!), rather than the .com TLD your site is hosted on. So they click through, assuming it's alright (they came from the admin user page after all), and this site looks identical to yours but has a login page. So you 're-enter' your details, but nothing happens. Or it redirects you elsewhere.
This is often the tactic of bank scammers who wish to target customers, inviting them to go to their website to 're-enter a banking password'.
This is just one more form of a type of security known as 'Social Engineering'.
Filter user's data removing '<', '>' - simply html tags. If someone can view user's profile there are possible XSS attacks through data.
Use HTTPS
Use Captcha.
Limit allowed characters for username in server side. for example alphabet and numbers, dash(-) and dot(.).
PS. Clientside encryption is not a secure way. but if you can't use HTTPs, clientside encryption is better than nothing.
Limiting characters, Its a simple way to protect your software from injections(SQL/XSS).
Suppose you've got a webapp that's passing usernames and passwords around in hidden form fields.
I know it's a very bad idea, but I'm interested in enumerating why... any thoughts?
update - This is a hypothetical question.
I couldn't find a resource that just enumerated the reasons - I know of plenty of reasons why it's a bad idea, I'm looking to see if there are any other reasons I haven't thought of and create that resource I was looking for. Thanks!
A number of reasons why it is a poor idea:
1) As pointed out, if you view source, inspect element, or anything similar, then the username/password is easily discovered.
2) Unless your transport layer is encrypted, they will be easily intercepted.
3) If the browser caches your html page, then that file with a username/password is now stored on that person's computer.
4) If that user saves the page to give to someone else, then their username/password goes with that page.
5) A POST method accidentally gets changed to a GET, now the password and username is stored in the server access logs....
Etc, etc.
There is no real reason to do it in my opinion, especially when you can use session cookies on the server, or some other method that doesn't expose private information to the client.
Edit: Come to think of it, I have done this once before. I put a password in a hidden field, however before doing so I encrypted it with a secret key known only to the server before printing it out, and then when I got the password posted back to the server, I decrypted it. Therefore the plaintext password is never with the client.
Edit 2: Should probably point out that the method described in the previous edit was not used for directly authenticating someone, as per hobbs point.
It's so easy for anyone with access to the current page ( might not necessarily be the same person who log into your application) to view the html source and get the user name and password.
If I log into my gmail, and leave my desk, and you come in and you can see all my email messages. But no matter what you can't see my gmail password. But if gmail passes the password around in hidden field format, then you can see my gmail password.
The page could get cached in a user's browser.
The page could get cached in a proxy server.
Worst of all, the page could get cached by a search engine.
In all cases the content containing username and password might be served to a person who is not supposed to see it.
I don't think storing a username in plaintext is so bad, and in some cases it might be beneficial to do so.
Storing passwords, however, are a different story. It would be very easy for someone to packet sniff your data going across the network (there are many points on its journey that this could happen) and logon using your credentials.
A golden rule I follow is never store a plaintext password anywhere, ever.
I think the biggest risk here is that any XSS vulnerability now allows password stealing. XSS is much worse than it seems. There isn't really any excuse for XSS vulnerabilities, but people make decisions such that they become rather inevitable.
Perhaps the second biggest risk is caching. These passwords are going to end up on disk and be available to any malicious code trawling through files. Having said that, most passwords can end up on disk through swapping and hibernation - it becomes a matter of probabilities.
Typically when I need an official resource for listing possible attacks or weaknesses, I turn to:
Common Weakness Enumeration
http://cwe.mitre.org/
Common Attack Pattern Enumeration and Classification
http://capec.mitre.org/
Taxonomy of Software Security Errors
http://www.fortify.com/vulncat/
Amazingly, storing username/password in a hidden form field is such an egregious error that it hits about 20 issues within the CWE.
Just to get you started:
http://cwe.mitre.org/data/definitions/352.html
http://cwe.mitre.org/data/slices/384.html
http://cwe.mitre.org/data/definitions/471.html
http://cwe.mitre.org/data/definitions/472.html
http://cwe.mitre.org/data/definitions/639.html
http://cwe.mitre.org/data/definitions/642.html
http://cwe.mitre.org/data/definitions/656.html
Well, the dangers vary depending on what you mean by "usernames and passwords".
If you're referring to the usernames and passwords being validated against, I invite you to choose View->Source in your web browser. This is no security at all.
If you mean the username and password of the user logging in being placed in a hidden field before being sent, there's absolutely no difference between that and your standard text and password fields. The only security risk here are passwords being sent in-the-clear without a TLS/SSL connection to encrypt it, allowing for packet sniffing to see the credentials.
Wiretapping, especially if the transport layer is not encrypted
unless all your pages are served over https it's bad because usernames and password are sent in clear text over the network constantly and can sniffed.
Even if all pages are served over https it's bad because if a user forgets to close his/her browser, anyone with access to the computer can view the source and read the password.
It gives the users a false sense of security and I would recommend that you change it if at all possible.