I am doing a bit of preliminary investigation for my school (I work for the IT department as a student). The students here have to change their passwords every 6 months, and many of them struggle with the (many) password rules that are enforced. That is, they often have to make several attempts at setting a new password.
The rules are:
Must be 8 characters or more in
length
Must contain 3 of 4 types of
characters (capital, lowercase,
number, special character)
Must not contain the user's first,
last or middle name
Must not contain the user's username
Must not match any password used
before
User must type password in twice, and
typed passwords must match exactly
I have a few questions:
Is it possible to create a web-based
password checker that provides
real-time feedback as the user types
in their new password? I am
imagining a checklist on one side of
the web-page where green checkmarks
are activated as the password meets
more criteria.
Is it possible to do perform this
checking securely and entirely
client-side?
Where would one start on such a task?
Is there a guide you can recommend?
Please keep in mind that I am not a web developer. Also, please leave any witty comments like "change the password policy" or "they're just dumb users" out of here.
Is it possible to create a web-based password checker that provides real-time feedback as the user types in their new password? I am imagining a checklist on one side of the web-page where green checkmarks are activated as the password meets more criteria.
Yes.
Is it possible to do perform this checking securely
As the lights go green, it exposes information about where in a password the requirements are met. That will leak data about the password to anyone who can see the screen.
and entirely client-side?
Yes.
Where would one start on such a task?
A list of rules in the HTML document with a FAIL image next to each one. Programatic versions of the rules in JS. Then just test each rule in turn in a loop on each keypress event on the password input and swap PASS and FAIL images depending on if the rule is followed or not.
You'll need to hit the server with an XMLHttpRequest object to check if a password has been used before. Make sure you only store hashed and salted passwords there though.
Please keep in mind that I am not a web developer.
Then I recommend you get one or become one.
Also, please leave any witty comments like "change the password policy"
Fine, leaving the wit aside and sticking to the serious issue:
If people have problems coming up with passwords that conform to the policy, then they will have problems remembering them. This will lead to an increase in people having to have them reset (more work for the IT dept) and in people writing them down (which is probably going to be less secure then a password that is easier to guess / brute force).
Most of the rules you specify can be checked in real time using javascript, more specifically using regular expressions. Checking whether the password has been used before should be done on the server side to be secure.
Is it possible to create a web-based password checker that provides real-time feedback as the user types in their new password? I am imagining a checklist on one side of the web-page where green checkmarks are activated as the password meets more criteria.
Yes, but you will need to know some javascript to do it.
Is it possible to do perform this checking securely and entirely client-side?
No, and yes, or yes and no, but not both. You can do the check entirely client-side (except for checking against previous passwords, which would need database access). But nothing, NOTHING, on the client-side is ever secure. Anything you do on the client-side should be considered a help to the user. All validation must always be made again on the server.
I don't want to be a smart-ass and tell you to change the password policy, and doing so because validation would be "hard to do" would be a bad choice, but I would like to recommend the following article to the one that has decided on the password policy: http://www.baekdal.com/tips/password-security-usability
Must not match any password used before <--that one is the only one that has to be performed server side, but can be done securely using hashes or some form or encryption, because a client side copy of said passwords would not be a good thing.
Regexp's are probably where you'd wanna start. If you're unfamiliar with regexp's in web development, I'd suggest you start here: http://www.w3schools.com/jsref/jsref_obj_regexp.asp. If you truly have no experience in web development, I'd have to ask how you got stuck with a job where you'd have to learn a new language to accomplish a relatively simple task. You'll definitely need to have an understanding of javascript to do something like this all client side. Oh, and I wouldn't recommend testing
Must not match any password used before
It's too risky to do this in a simple way client side and complicated to do it securely without bringing in help from outside libraries, etc. Hope this helps and good luck!
Related
I've got a question which would be applicable to an MVC based platform, but I guess also applicable to any web based platform which handles user form inputs.
What are the best practices, and ideal stage from which to remove trailing/leading whitespace from user input?
I see this could happen at a few stages:
Immediately Upon User Form Input - ala Javascript functions to strip as they type/pre-submission
Inside the Controller on Params Submission
Intermediate Model/Attribute Methods
Prior to or upon Database Persistence
What is best practice in this regard, and specifically the pro's/con's for doing it at a certain stage, or multiple?)
I think it depends on the type of application:
For a standard web app, I would say you definitely want to clean data on the browser sometime before submission so that you can validate it (for ex. an email would fail validation if it has a leading space or a length check). It is better to validate without sending data to the server when possible.
If you are writing an API, especially a public one, I would definitely clean the data server side or return an error. You can't trust clients to send you clean data. I would probably do it in the model before validation which shouldn't be to hard to do automatically.
If bad data can cause a security issue (XSS or SQL injection) then you want to clean it on the server as well as the client. Even on a web app there is nothing stopping a malicious user faking a request from a web browser. If spaces in the data won't break anything then this may not be necessary (if someone 'maliciously' adds a leading space to their blog title it might look weird but it is only going to harm them)
This is a very opinion based question I think. It would depends on the persons who is implementing and also the application.
If you don't have to clean immediately after user input, I would say avoid #1 since it will be confusing to your users while they are typing, and also it can have a performance impact on slower/smaller devices.
#2 and #3 will both be very similar, a nice thing about #3 is that if you're using the same property in many places, your logic for trimming will live in only one place, but both will run on your server which takes away the perf hit from client device.
#4 depending on your DBMS can be very easy or difficult to implement.
I would personally choose #2 or #3, but again that's my opinion and someone else can have a completely different one than mine.
Also you certainly don't need to do it multiple if you get one stage right.
I quite often use captcha codes to secure forms. Until now I check the user-entered captcha solution only on the server side for obvious reasons.
For all other form fields I do a javascript validation on the client since this faster and more user-friendly; (Of course I do a second check on the server-side), But for the captcha field, I just checked if it's filled out.
My question:
Would it be safe to do a client-side JavaScript validation by using the hash key (e.g. MD5) of the captcha-code? Doing it with the hash key wouldn't reveal the captcha code itself to bots and should be quite safe, right?
But maybe I am completly wrong with this idea...
Thank you for your insights!
Safe enough I'd say, but that may help OCR bots into checking whether they got it right without trying their luck on the server and risking losing the current captcha (as the server would invalidate the code if an incorrect answer was supplied and won't give you a second chance to try again using the same captcha).
Let's say an OCR bot has trouble telling whether the last letter of your captcha is a lowercase L or the "1" digit ? In a conventional captcha without client-side validation, the bot just tries its luck, if it guesses wrong the server logs the failure and resends it a totally different captcha, so the OCR has to start all over again.
Now imagine the above scenario but with client-side validation, here the bot has a way to verify whether they have the right answer without notifying the server about it, so in this case, if the bot is unsure, it tries all of the possibilities against the hash and only submits the right answer. Basically, this gives the bot the ability to make mistakes without telling the server about it and without having to start all over again.
Finally, I don't have precise numbers in mind, but even with a different salt each time, depending on the number of possibilities (like 4 alphanumeric characters, case-insensitive) it may be possible to bruteforce every single possibility in a reasonable amount of time without even making an OCR. To mitigate this you should use many iterations of the hash so that it becomes computationally difficult to try all possible answers.
Sounds doable, however you should definitely consider a long and random salt to prevent a simple attack based on precalculations.
More formally, you'd have to send the image, a long random salt and the hash value. Then, client side, you would calculate the hash of the input text concatenated with the salt and compare the result to the hash.
Because of the long random salt, the attacker's precalculated set would have to be enormously large to reflect all possible salt values.
Also, forget about MD5 as it is considered unsafe. Use a stronger hash function.
Also note that this would only be something that could possibly enhance the user experience (no need to POST the page in case of mistyped captcha) but definitely you can't do it only client-side. The actual verification must be done at the server.
I just read an article which states:
Internet domain addresses opened up to wave of new suffixes
Internet naming board approves huge
expansion of approved domain
extensions with .hotel, .bank, or
.sport auctions likely.
Twenty-six years after .com was first
unveiled to the world, officials have
swept away tight regulations governing
website naming, opening up a whole
world of personalised web address
suffixes.
But... I just learned how to validate email addresses by checking (among others variables) the number of characters used after the dot (i.e., .com, .fr, etc.). What now?
Analysts say they expect 500 to 1,000
domain suffixes, mostly for companies
and products looking to stamp their
mark on web addresses, but also for
cities and generic names such as .bank
or .hotel.
Maybe this is not a problem. But how are we going to validate email addresses? What’s the plan?
IMO, the answer is to screw email validation beyond <anything>#<anything>, and deal with failed delivery attempts and errors in the email address (both of which are going to happen anyway).
Related:
How far should one take e-mail address validation?
As I've answered elsewhere, this regex is pretty good at handling localization and the new TLDs:
(?!^[.+&'_-]*#.*$)(^[_\w\d+&'-]+(\.[_\w\d+&'-]*)*#[\w\d-]+(\.[\w\d-]+)*\.(([\d]{1,3})|([\w]{2,}))$)
It does validate Jean+François#anydomain.museum and 试#例子.测试.مثال.آزمایشی, but it does not validate weird abuse of those nonalphanumeric characters, for example '.+#you.com'.
Validating email addresses beyond a check for basic, rough syntax is pointless. No matter how good a job you do, you cannot know that an address is valid without sending mail to it and getting an expected reply. The syntax for email addresses is complex and hard to check properly, and turning away a valid email address because your validator is inadequate is a terrible user experience mistake.
See What is the best regular expression for validating email addresses?.
It’s with the current TLD's already quite impossible to verify email address using regex (and that’s not the fault of the TLD's). So don't worry about new TLD's.
The way I see it, the number of TLDs, while much larger than today's, will still be finite and deterministic - so a regex that checks against a complete list of possible domain suffixes (whether that list is your own or, hopefully, provided by a reliable third-party such as ICANN) would do the trick.
I'm new to ColdFusion, so I'm not sure if there's an easy way to do this. I've been assigned to fix XSS vulnerabilities site-wide on this CF site. Unfortunately, there are tons of pages that are taking user input, and it would be near impossible to go in and modify them all.
Is there a way (in CF or JS) to easily prevent XSS attacks across the entire site?
I hate to break it out to you, but -
XSS is an Output problem, not an Input problem. Filtering/Validating input is an additional layer of defence, but it can never protect you completely from XSS. Take a look at XSS cheatsheet by RSnake - there's just too many ways to escape a filter.
There is no easy way to fix a legacy application. You have to properly encode anything that you put in your html or javascript files, and that does mean revisiting every piece of code that generates html.
See OWASP's XSS prevention cheat sheet for information on how to prevent XSS.
Some comments below suggest that input validation is a better strategy rather than encoding/escaping at the time of output. I'll just quote from OWASP's XSS prevention cheat sheet -
Traditionally, input validation has been the preferred approach for handling untrusted data. However, input validation is not a great solution for injection attacks. First, input validation is typically done when the data is received, before the destination is known. That means that we don't know which characters might be significant in the target interpreter. Second, and possibly even more importantly, applications must allow potentially harmful characters in. For example, should poor Mr. O'Malley be prevented from registering in the database simply because SQL considers ' a special character?
To elaborate - when the user enters a string like O'Malley, you don't know whether you need that string in javascript, or in html or in some other language. If its in javascript, you have to render it as O\x27Malley, and if its in HTML, it should look like O'Malley. Which is why it is recommended that in your database the string should be stored exactly the way the user entered, and then you escape it appropriately according to the final destination of the string.
One thing you should look at is implementing an application firewall like Portcullis: http://www.codfusion.com/blog/page.cfm/projects/portcullis which includes a much stronger system then the built in scriptProtect which is easily defeated.
These are a good starting point for preventing many attacks but for XSS you are going to end up going in by hand and verifying that you are using things like HTMLEditFormat() on any outputs that can be touched by the client side or client data to prevent outputting valid html/js code.
The ColdFusion 9 Livedocs describe a setting called "scriptProtect" which allows you to utilize coldfusion's protection. I've have not used it yet, so I'm not sure how effective it is.
However, if you implement a third-party or your own method of handling it, you would most likely want to put it in the "onRequestStart" event of the application to allow it to handle the entire site when it comes to URL and FORM scope violations (because every request would execute that code).
Besides applying all the ColdFusion hot fixes and patches you can also:
Not full proof but helps, Set the following under CFADMIN > Settings > "Enable Global Script Protection"
Add CSRFToken to your forms http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
Check http Referer
Add validation for all User inputs
Use cfqueryparam for your queries
Add HTMLEditFormat() on any outputs
Besides Peter Freitag's excellent blog you should also subscribe to Jason Dean's http://www.12robots.com
As far as I read from here, the fact that captchas are not 100% secure.what can be used instead of captcha? As a programmer what do you think? how to solve this issue?
Edit: thanks for all answers.
This is an unsolved problem, and will become more unsolved as time passes. The better the OCR tools get, the smaller the gap between humans and computers, and the harder it will be to tell them apart. Eventually, computers will be indistinguishable from humans, and then the game will be up.
If your server wants to make sure that a human is at the other end of a TCP pipe, there isn't a turing-test in existence that won't eventually be defeated (and there probably never will be one). CAPTCHA is doomed, it's just a matter of how soon.
Of course, that doesn't mean it's all over as far as human authentication is concerned. It just means that automated turing tests, as convenient as they are, won't be an effective way to achieve this for very much longer.
Captcha involving human reflexion (like calculation, really simple question, and the like).
Session tokens
randomly generated hidden input which requires to be null, on the server side generate a random identifier, keep it in a session for a while. If the input is filled and not null, then it might have been filled by a robot, do your users will fill an hidden input ?
I think it really depends on what you are trying to control over the use of captcha.
Further explanation of a suggestion made by Boris:
randomly generated hidden input which requires to be null
The idea is that your form contains several invisible inputs, their type should probably not be set to hidden, but they should be invisible to a human (e.g. set width or height to 0). The initial content of these fields should be empty. If a human fills out the form, the field will be empty, because the human cannot see the field in order to enter anything into it, but if a bot fills out the form the field will (possibly) not be empty, because bots usually just blindly enter something into every field.
Thus, you can distinguish between a bot and a human based on whether the content of this field is empty.
Although captchas can be broken, Capthca's only add to security reCapthca is very good, and a trained OCR like Tesseract is going to have very limited success in breaking it. However, there are outfits that use Human Computation to break them for pennies. But this makes attacks against your system more expensive, and thats the best you can hope for. Cryptography can be broken with brute-force. All password hashes are breakable, but we still use them because it makes it harder for the attacker.
Most of the "solutions" on this thread are "Security Though Obscurity" and you should be wary of these quick fixes to a very complex problem.
Captcha's are used to determine that an actual human being is doing the request, not a machine. Captcha's and captcha-like systems will upgrade, and so will the technology to break them.
So how do you proof that you're talking to a human and not a computer? You could for instance require users to engage in a chat session and have small conversation. There's no AI nowadays that pass the turing test.
So the answer is, no system is perfect. Don't try to solve this issue, but try to find a way to reduce the impact of this.
In the long run government could run openid servers as digital passports for their citizens.
It would be a clean way to identify human beings and prevent sockpuppeting.
At the moment on my website I opted for simple questions. Some questions I've used in the past:
What is two to the power of one?
What is 2+2? (this one was hacked though so don't use it)
What is the name of this website domain?
What is the sum of two and two?
Some other nice ones could be
type in 'stuff' to this box as a spam check
What does 1337 look like? (using only letters)
the current year is?
The best way I can think of is using something unconventional, like a special hidden field that should be null (or another specific value) that robots will mess with.
If some robot maker adjusts his robot for your site, you'll have to quickly change the captcha to something different. It will (hopefully) take a good while before another robot maker adjusts his robot for your site.
Basically, it's a security through obscurity that has to constantly change to remain obscure.
This won't work very well if someone is specifically targeting your site.
Its just an idea, id used that in my application and works well
you can create a cookie on mouse movement with javascript or jquery and in server side check if cookie exist, because only humans have mouse, cookie can be created only by them
the cookie can be a timestamp or a token that can be validate
Gets the coordinates of the mouse, determine whether the coordinates have changed, you can determine whether it is a robot.
Then encrypt the coordinate data.