As per the title really, just what can be done to defeat key/keystroke logging when authenticating access?
I have just posted a related question (how-to-store-and-verify-digits-chosen-at-random-from-a-pin-password) asking for advice for choosing random digits from a PIN/password. What other reasonably unobtrusive methods might there be?
Any and all solutions appreciated.
One solution to defeat keyloggers is to not care if they capture what you type.
One time passwords (search: "OTP") are one solution. Smartcard authentication is another.
A hardware-based keylogger will not be fooled by any solution that requires the use of a keyboard. So, to bypass those you will need to have input through the mouse only. But software-based keyloggers can be stopped by adding a keyboard hook in your own code which captures the keys and which does not call the next hook procedure in the hook list. But keyboard hooks tend to trigger antivirus software if used incorrectly and will cause bugs if you use them in any dynamic library with the wrong parameter.And basically, a keylogger will use a keyhook to capture keystrokes. By adding your own keyhook on top of the malware keyhook, you'll disable the keylogger.However, there are keyloggers that hide deeper in the kernel so you'd soon end up with a keylogger that will bypass your security again.Don't focus too much on the danger of keyloggers, though. It's just one of the many methods that hackers use to get all kinds of account information. Worse, there's no way that you can protect your users from social engineering tricks. Basically, the easiest way for hackers to get account information is by just asking their victims for this information. Through fake sites, false applications and all kinds of other tricks they could just collect any information that you're trying to protect by blocking keyloggers. But keyloggers just aren't the biggest dangers.
One suggestion was to use pictures of cute kittens (or puppies) for the user to click on. What you could do is use a set of 10 pictures and let the user pick four of them as their "pincode". Then, whenever the user needs to enter their code, display the pictures in any random order so hackers have no use for it's location. If it's a web application, also give the pictures a random name, and just let the server know which is which. To make it even more complex, you could create 10 sets of 10 pictures, where every picture displays a single object but from a slightly different perspective, different angle or in a different color. Set 1 would be a chair, set 2 a table, set 3 a kitten, set four a puppy, etc. The user then just needs to remember: Table, kitten, chair, puppy. (Or puppy, chair, chair, table. Or kitten, puppy, puppy, puppy...)
You could have a clickable image with the letters on it. Your users will be pretty mad though...
You can allow to use only on-screen keyboard to enter password.
Or you can write module (on flash for example) for handwriting (via mouse or stillus) passwords recognition.
The only real way is a proper second factor authentication: Either something the person is: fingerprint, iris scan. Or something they have: one-time password list/generator; crypto-generator.
Assuming that only keyboard, and not mouse input is captured, you could type the password out of order moving the cursor with the mouse.
I really like the one time approach better, though.
How about a variation of standard password. For example you could have a list of words and have program leave out random letters from each word. In addition to that it would leave out one word from the list which user would have to remember and type it out.
If the words form a sentence, it would be easier or users to remember it but on the other hand creation of the sentence would be more difficult because you'd need to use words which can't be guessed from sentence's context.
Another variation of this could be to have program at random ask user to replace all letters i with 1 or a with 4 or to place say letter R after every third letter A or something similar.
Basically have a password which would be modified at random and have it instructions displayed to user how to modify the password.
Now that I think of it, I'm not sure how unobtrusive my ideas are...
The online banking portal of my bank has a nice way that I find very unobtrusive. When creating the account, you define a 6 digit PIN (additional to a normal password). After entering your password, you're asked for 2 digits of the 6 digit PIN at 2 random positions. For example, if your PIN is 654321, it'll ask your for digits 2 and 5 and you'll click on 5 and 2 (it has a numpad with digits to click on). Even if you'd enter the digits with your keyboard, it would still be kind of safe because the attacker won't know which digits you've been asked for (unless he captures the screen as well, maybe using tempest).
So, short answer: Ask only for some parts of the password/PIN, in random order. Having the user use the mouse increases security.
One more idea: If you have a PIN (numerical password), ask the user for modifications of certain digits, e.g. "2nd digit plus 3, 4th digit minus 1".
Related
If a system has a set of 40 pictures and each user selects 20 pictures as their favorite pictures for password authentication.
The system will authenticate a user as follows: present 2 pictures and the user will select the one that is from his favorite pictures.
The system will repeat the process 20 times, hence 40 pictures.
If the user has selected their 20 pictures successfully from the 20-pair sets, they will be logged in.
What is the search space for an attacker to crack the system and login as a user?
Here is my try: I thought that the attacker will use a program and brute force as much as 220 times.
Is this system more secure than a standard password authentication system?
I see it as impossible for this to be more secure than a standard password-based system.
Look at it this way: if I use a password that is 12 characters long, based on a standard US keyboard being able to produce 96 different characters, that is 612,709,757,329,767,363,772,416 different combinations (9612).
Your picture-based system, on the other hand, only has 1,048,576 different possible combinations (220).
In summary, your picture-based system would be cracked in just 0.000524288 seconds! The password-based system, however, would take 9.7 million years to brute force!
(Based on: number of possibilities รท 2,000,000,000 = number of seconds)
First of all, the user experience might be bad. Choosing 20 pictures out of 40 in 20 iterations may take long time and might be boring. Even if users decide to go through it, they may prefer pictures easier to remember, because accurately remembering 20 pictures itself is not a simple task.
As analyzed above, the password space is not so big. And, users may have strong tendencies to choose pictures. For example, a user may prefer a specific color or theme, something like that, which makes it easier to attack than simple brute force.
I have a vb application where I was using an online mysql database for user access. The online database had username, password, then a bunch of single digit (basically yes/no) fields for determining which items that user was allowed to access. When a user would log in, the database retrieved all the 'yes' answers and enabled those buttons, and retrieved all the 'no' answers and disabled those buttons.
My issue is there is a very good possibility that any given user will not be online. So I thought of copying the online database to a local device (this program is going to be running on windows tablets that may or may not have internet - possibly never having internet connection). This would suffice except a user may use a different tablet and that device wouldn't know what the user is allowed to access (based on a lack of internet connection).
So my new approach is when a user registers, having them provide first name, last name, phone number, and email address. At this point in time I would also select which buttons they are authorized to use. I want to put all that info into a code (probably a hash) so the next time the user would login (online or offline), they would use their first name, last name, and the generated code. The user could even go to a different device and still get the same result. I hope this makes sense.
So basically I am looking for a way (I am pretty sure hashing is involved) that would allow a user to register with some info, receive a code that ties it together, then log on to any windows tablet that is running my program without the device ever having to go online to download a new list of authorized users.
Thanks in advance.
A hash is part of what you're thinking of, but not the whole thing. A key part of a hash is that it's not reversible, and so you can't use a hash on it's own to communicate information like which buttons to enable/disable. It does sound like you also need to implement hashing elsewhere in your system (NEVER store unhashed passwords!). The rest of what you need for this question are secure check digits.
The idea is that you generate a number with a few holes/empty spaces, where different parts of the number have different meaning. It might look something like:
4325_-23R3_-F257_-D982_-__
A few of those characters are a hash of the user information, with the bits from other characters corresponding to your Yes/No database fields. Once you have this much, you have an algorithm (using a secure key) that computes what characters belong in the missing spaces, and then you can issue the final number to your user. Your software will take the number entered by the user, and check to the make sure the check digits it comes up with match the check digits entered.
There is a downside to this approach. Allowing offline activation means including including the key used to compute the check digits with your product, and as with any digital security once you put that kind of thing out in the wild crackers will be able to find a way to get at it.
Now let's move on to the big gaping security hole in your current code. You state that your database stores a username and password. I'm hoping that you're just simplifying things, but this is a huge problem, to that point that I can't in conscience leave it unchallenged. Instead of storing the actual password, you should hash the password and store only the hash. When someone wants to log in, you hash the attempted password they try to use and compare the hashes. This is a big deal, and if you're not doing that, you're doing it wrong.
That also over-simplifies it a bit. You also want to salt your passwords before hashing them, to help thwart dictionary attacks on common hash results. Additionally, choice of hashing algorithm matters. md5 does not cut it here. Your best option is bcrypt or scrypt, but you can use sha1 for now if you really have to.
The biggest thing to know here is that you should never try to build your own authentication system. It's easy to get it close enough that it passes all your tests, but is still wrong in some subtle way that won't know about until a year later when you find out you were hacked six months ago. Instead, look for a pre-written component or product for your existing platform to handle this. Rely as much as possible on code from projects (and programmers) that specialize in this area.
I am trying to put together a checklist things I need to keep in mind when creating forms. I know I need to filter input content. I already am filtering for errant html and scripts, escaping mysql, and limiting to data types(phone numbers are 10+ digits with training extension digits, email has to be email, strings cannot contain html or code, etc.), and word or character limits (names max out at 4 words separated by whitespace, etc.). But what else should I be doing and what are good ways of doing them?
This validation will be taking place on the server, but I am looking for best practices across platforms. The data will be coming in using POST, so I don;t have to worry too much about mucking about with the url. Also the form presentation, with hinting, js input masking is handled, and pretty much all the client side stuff is in place.
Validation down to its simplest term: only accepting what you want.
For example, if your telephone field should only include numbers (in no particular phone number format) and no longer than 20 numbers, you can check it against regular expression to make sure that it is what you want to accept, i.e. ([0-9]{7,20})
Another example, Twitter. It only accepts username up to 15 characters, alphanumeric and consisting of underscores. So the validation regex might something be: ([a-zA-Z0-9]{1})([a-zA-Z0-9\_]{0,14})
Form validation can also be in the form of security check. One could be honey potting, form validity and so on.
Form Honey potting: Preventing automated/spamming of your form submissions
Form Validity: Check between the time the form has loaded and the time of form submission. If it is too short, the form might be submitted by a bot. If it took too long, the data might be old and expired.
CAPTCHA: another level of bot prevention / human only form validation.
The always great smashing magazine has some great tips:
http://www.smashingmagazine.com/2009/07/07/web-form-validation-best-practices-and-tutorials/
But if I could offer my own:
Make it secure but usable.
Use client side validation along
with server side validation
If you post back with errors, make
sure the users' information is still
populated in the form
Limit the field size in HTML forms.
Of course, all this is assuming you're using web forms.
Commenter S. Lott is correct: Escaping should be taken care of automatically by the framework. If you're not working with an explicit framework, then at the very least, the utility functions you use to access the database and display data on the page should escape for SQL and HTML, respectively. If you have to worry about escaping in your validation code, sooner or later you'll make a mistake, and some twelve-year-old script kiddy will replace the contents of your web site with horse porn.
Stuff that makes sense in the context is good, stuff that doesn't make sense is bad.
If this site filtered for HTML, then we couldn't give HTML examples. Instead it processes the HTML so that they are output escaped, rather than as HTML.
Beware of over-validating. < is not necessarily bad, there are all sorts of reasons people will use <, > and especially &.
Likewise, while Robert '); DROP TABLE Students;-- isn't someone you want signing up at your school, if your preventing that means that O'Brien, O'Tierney, O'Donovan and O'Flanagan can't sign up, by the time O'Donnell is refused he's going to think it's anti-Irish racism and sue you! (More realistically, I do know people here in Ireland who go off to find a competitor when a SQL-injection prevention script blocks or mangles their surname - though more often they've just found yet another site that isn't preventing injection, as either will fail on their name in some way).
Validation, as opposed to security-checking is about making sure something plausibly reflects reality. In reality personal names have ' in them and company and town names have & in them all the time, and "validation" that blocks that has turned valid data into invalid. In reality, credit card numbers are 16digits long (some debit cards 19digits) and pass a luhn check, email addresses have a user info part, an # and a host name with an MX record. People's names are never zero-characters long. That's validation. Only reject (rather than escape) if it genuinely is invalid.
You may want to check out OWASP http://www.owasp.org/index.php/OWASP:About. Especially if you're planning on handling credit cards.
I'm looking for ideas on how to implement some type of fast login scenario for an application that will allow employees to quickly login.
I work with an organization that has employees rotate every 30 minutes to a different location. If there are 3 employees, then the first employee won't come back to the checkout station for an hour. The checkout station is a higher traffic area where different things are borrowed by customers. Right now they have a generic login, but the organization wants to track which employee checked out/in a borrowed item. The problem is when they rotate there are customers there many times and having them logoff and login either via a workstation login or an application login is too slow for customer service.
Any suggestions?
I think a fingerprint reader would work well for logging in users. Then, they wouldn't have to type anything to log in.
There are plenty of biometric SDKs online that should be able to help you with this. And, I think some commercial readers will do something similar already, so you wouldn't even need to write any code.
Here's an article on Microsoft's Upgraded Fingerprint Reader
Also, you can have them scan once to log in, and once they are logged in, they can scan again to get logged completely out of the system (instead of just locking the screen or forgetting to log out and walk away.)
Use an application-level login, but make it only based on typing in their employee ID. This will simply identify who they are, exchanging security for speed while not giving up identity. Using employee ID's for this is a good way of guaranteeing uniqueness. I've seen systems like this work in retail, and it's really fast. Employees get used to typing this number into the console.
I'm not sure if it's in your budget but this sounds like a good use for those little button 1-wire devices. Basically it's an electronic "key" that is about the size of a button and can be read very quickly.
So Employee A goes to the station, puts his button on the pad(takes like 2 seconds) and he's logged in. When he needs to leave he pushes one button to log out, then employee B can come and log in, etc etc.
a picture of the button:
My site uses captcha of 6 digits, however if the attacker try all combinations, chances are he will successfully submit the form fraction of the times.(1/million in theory, much more in practice since the random number generator I use is not truely random).
Is there anyway I can further prevent him from succeeding? One way is to prevent anyone from form submission for 5 minutes after a certain number of tries(eg.20), the problem is that if I store the number of tries in session, and the attacker creates a session for every try(naturally since he uses a program, not a browser), then it would not work. And I don't want to modify existing db schema to accommodate this logic.
Another way is to increase the number of captcha character used, which causes user inconvenience.
All advises are welcome.
regenerate a new number after each attempt, or after x attempts =D
I would recommend adding letters. That will make brute force much harder, than adding more digits.
EDIT: You can also, slow done the answers after getting some incorrect attempts. Add for example, 5 min delay.
Check the IP addresses of incoming connections. If the same IP address tries too many times, rate limit them harshly and if it continues for a long time, block them completely.
Of course it's not a perfect solution, but it will make it more difficult.