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.
Related
I'm thinking through how to develop a validation on my Rails app that essentially checks to make sure that the credit card used for any given transaction by any user is unique in our system, such that all credit card may be used to purchase an item only once across the entire application for all users, for all time.
The thinking behind this restriction is that this app will sometimes run time-sensitive promotional deals, and we want to do our best to institute a "one purchase per credit card" system for these deals.
I was thinking of hashing the credit card number and just storing that hash in the db, then cross-referencing it at the time of each new purchase (so my payment gateway keeps the actual number, and I just keep a hash in the DB), but on further research, this seems like a bad idea.
So I'm back to the drawing board and looking for new ideas. Anyone know a good approach to this problem, while keeping as PCI-compliant as I can be?
I'm developing with Rails 3 and using ActiveMerchant to integrate with my payment gateway, Authorize.net, if that helps at all.
Certainly some hashing is a bad idea - either because it's low security, has some intercepts, or so commonly used there's rainbow tables. That doesn't mean all hashing is a bad idea - the only way to cross reference is going to be some way of uniquely and predictably identifying the information. Unless PCI specifically prohibits it - hashing is still the way to go.
Salt
Make sure you salt your hash - this prevents rainbow attacks, or at least requires the rainbow-attacker build a table with your salt in mind. In particular if you can keep the salt reasonably secure {I say only reasonably because in order to generate you need to have the salt which means it'll be in code somewhere}.
Choose a Good Algorithm
While MD5 is now infamous, and implemented in all kinds of languages, it's also so common that you can find pre-made rainbow tables. It's also extremely quick to generate a hash. Your system can probably tolerate a small amount of delay, and use a much more processor-intensive hash. This makes the cost of generating a rainbow table much more expensive. Check out the Tiger algorithm for example.
Hash more than once
If you have multiple related data points, multiple hashes are going to make it way harder to do a rainbow attack. For example: Hash(Hash(Card#+salt1)+expireDate+salt2) - requires knowledge of both the card # and the date to generate (easy for you) but can't easily be reverse-engineered (rainbow requires for every card # * every useful expire date + knowledge of both salts).
Edit: (your comments)
Reasonably secure: Only transmit it over an encrypted connection (SFTP, SSH), don't store it unencrypted - including live/iterative and backup copies, keep the file with the salt outside of the web tree (cannot be directly accessed/accidentally released), make sure permissions on the file are as restrictive as possible (don't allow group/global file access).
Dynamic salt throwing a random value into the hash is great for reducing rainbow attacks - you store that random piece in the table with the hashed value - now when building a rainbow you have to build one for every dynamic salt. However for your needs you can't do this - you need to know the right random salt to use the second time you create the hash (otherwise you'll never get an intercept on the second card use)... for that to be predictable/repeatable you'd then have to base the dynamic salt on some part of the number... which is effectively what multiple hashing with another data point does. The more data points you have the more you can hash in this direction - if you have the CVV for example (3 hashes), or perhaps you hash 8 digits at a time (for a total of 3 hashes: hash(hash(hash(1..8+salt1)+9..16+salt2)+expDate+salt3)).
Best Hash it's a moving target, but there's a good discussion on security.stackexchange. Which points to SHA-512.
faking your true credit card number online is the best way to prevent this from happening. Citibank clients can login and make use of this tool provided with all accounts. Just generate a number and exp date for use online, and all is fine , for now.
I think you are looking in the wrong direction. I would just check last 4 of card, ip and shipping addresses. The risks of storing that data versus the damage if a small number of users gamed the last 4 & ip solution is not worth it. (He says not knowing the nature of the purchases.)
Since address isn't collected...First 4, Last 4 and 4 Digit Expiration (all hashed of course) should provide the uniqueness you need to ensure that card was only used once.
If you want a "one purchase per user" system then why don't you just check the user's purchase history whenever they try to buy a special-purchase item to ensure that they haven't bought it previously?
user could register for multiple accounts.
although by checking users history, as well as enforcing 1 item per address for each purchase- you will likely be fine- you could also limit things by users name/ birthday/ whatever other identifying information.
Credit Card information can also change by the way- its actually very easy to purchase 100 gift credit cards with unique numbers so if you want to police things down to the most minute level... I dont think you will be able to just by cc numbers
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 tried using RoboForm but it's like Oracle - incredibly complex. We could never get it to share the corporate passwords but keep individual ones for each user.
Anyone know of a good login mananger?
We want one that has a shared company repository and individual repositories for each user for their person passwords. Preferably simple enough that there's only 5 - 10 options and only 1 password per user.
Have you looked at LastPass? It allows sharing individual passwords, but not a complete repository of passwords (at least as far as I know) so it may not fit your needs.
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".
Out of interest and because it infuriates me, I was wondering if SOmebody here might happen to work for a bank or otherwise know the answer to this.
I've used a few online banking sites (UK and N.America) and they universally enforce a password pattern of /[\w\d]{6,8}/ Sometimes, maybe you get to use underscore, but never ever do you get to have /.{6,20}/ that you get (more or less) with just about every !banking site you'll encounter.
I have been told that this is to do with storage space, but the maths don't seem to support that. Assuming that banks keep shadow tables for your password record, let's generously say an average of 10 per account, then doubling the allowed length of the password and doubling the bit width of the character set based on an 8char 8bit existing format means an extra 11*2*8 = 176 bytes per account, so ~168Mb per 1M accounts. Let's say it's a gigantic bank supporting 100M accounts - that's still only 16Gb!
It can't be that simple can it? Surely my numbers are off base.
Or is the answer here that banks being banks they have no better reason for this than they're plodding dinosaurs.
Does anyone know a technical reason why my password for www.random.com/forum is stronger than the one for my bank?
If the stories I've heard about certain banks are true...
It's because whenever you enter your password:
The web server sends it over a half-kilometre-long serial cable to an old 386 in an abandoned office, running the UI (Compiled using a custom-hacked version of Borland C 1.0) that was used by bank managers in 1989, which doesn't have a serial interface so it has to go through another device that simulates keypresses on an AT keyboard.
This program inserts your request including your password (encrypted using a custom algorithm that's too weak to be used anymore but which cannot be disabled in the software) into a FoxPro database on a NetWare file server in a different abandoned office at the opposite end of the building (just because it would fall to bits if they tried to move it.)
Back in the 1st abandoned office another old 386, constantly polling the FoxPro database for new records, detects this request and forwards it over an even slower serial cable (this time in EBCDIC) to another box in a 3rd office that is emulating a PDP11 running the actual COBOL program that maintains the accounts.
Unfortunately they also still need the real PDP11, because it had custom microcode for another secure encryption algorithm (which they can't extract or the anti-tamper device will erase it.) The PDP11 can't handle the increased workload of all accounts opened since 1981 (the year of their first unsuccessful attempt to retire it) so now (via another layer of screen scrapers and emulated hard disks) it is tricked into performing a subset of functions (including password verification) on behalf of the main server.
So your password can only use the common subset of the character sets supported by all these systems, and can only be as long as the shortest database field involved.
I actually work in a bank right now, and have worked in quite a few in the past.
The primary reason that this happens is that in general the people who are ultimately responsible for making these decisions are not the people who end up implementing them.
The "Business Unit" of a bank are the non-technical business experts who end up making these decisions.
In many cases, technical objections will be overruled for political or business reasons. But this isn't exclusive to banking. It happens in any industry where technical considerations are often not the primary concern.
Banks use online services primarily as an interface to legacy systems. Your password is probably being processed by an IBM mainframe somewhere, written in Cobol, and the password structure may have been designed in the 70's.
In addition, because banks are such political structures, the management primarily sees "concrete" results so issues such as security are not addressed until it becomes a hot issue and then there is an "initiative" to address it.
At one bank I worked for, the production password was the same as the userid (same idea as logging in with "root" "root"). The user passwords could be reset online to a combination of first N letters of your last name + last 4 digits of your SSN, so any user could reset your password if they knew your name and SSN and loginas you .
Probably most of banking systems were developed long time ago, when 8 character passwords were considered secured. I don't think anyone would consider brute forcing passwords from banking accounts anyway, 8 characters it still a lot. I bet all banks block an account after 3 attempts or so.
Here is a "bug" I got logged in Bugzilla regarding a site I'd built for a client recently (not a bank, thankfully!):
"It seems that the user is forced to use a ! or _ in their password* which seems a bit odd to me. Can this ben updated so that it is a 6 - 8 digit password that can only use alphanumerics?"
Actually, it was at least one non alpha-numeric character