Given an application where users identify themselves by some id with an accompanying PIN code, how should PIN codes be saved?
The PIN codes are fixed length (6) and comprised entirely of digits. Once an account is selected, this pin code will be entered into pos terminals for authentication.
It is best of course, not to save the pin codes in the database as raw text. However, even good password storage techniques (ex bcrypt) seems to fall short. Due to the nature of pins, it is trivial to simply try all possibilities. (Ex try 000000-999999 on a given bcrypt hash). Is there a better way of saving PINs then?
Related
In an EMV chip card with two AIDs, it is correct to use different IMK-AC keys for each AID or the same IMK-AC key for both AIDs?
I'm asking this question because we are having problems validating the ARQC for an EMV chip card. The ARQC validation is success only when the card is using one AID, and the ARQC validation is failing when the card is using the other AID. We have tested this several times and have the same result. My theory is the IMK-AC used to issue the AIDs are different, but I don't know if that makes sense?
Is there any way to know the IMK-AC KCV in an AID EMV chip card?
Also, In the TVR (terminal verification result) for the transactions are:
ARQC Success: 8000048000 (Online PIN entered ON)
ARQC Failing: 8000008000 (Online PIN entered OFF)
I don't know if the TVR could affect in any way the ARQC validation?
I'll appreciate any help on this issue.
Thanks!
Two different applications and hence two different card numbers, correct ?
While you personalize, IMK AC will not be sent to card, it is a key derived from the IMK-AC, diversified with pan and card sequence number, called Unique derivation key sent to the card, and hence both cards will have two UDKs even though the IMK-AC is same.
Since AID is different, ensure the ARPC verification is appropriate for the Cryptogram Verification Number. You can get this from 9F10(Issuer Application Data).
The value in TVR do not matter for ARQC validation, but what received from the terminal should be used for verification since it was used for generation by the chip.
You can add some logs from terminal, host and HSM here ( after masking sensitive data if performed using a live card ).
I am building a device with GSM Modem and a SIM card. I would like to protect the SIM card with a pin to prevent its misuse when the devices are installed on field.
Storing the pin for associated SIM into each device would be cumbersome. Also, if SIM is replaced, I want the device to automatically know the PIN for the new SIM. So I was thinking of using a one way hash function to generate the pin from one or more properties of the SIM like its IMSI, ICCID, SIM Card Group Identifier, Service Provider Name etc.
When a SIM is inserted, the device can dynamically calculate the correct PIN based on these properties.
(I know that security based on secret algorithm violates the basic principles of computer security, but in this case I don't need it to be fool proof - I just need something better than leaving it unprotected.)
The problem is that none of these properties can be read before entering the PIN.
Is there any other property that can be read without entering the PIN? Or do you have any work around that does not require storing of PIN on the device in advance?
Yes, it should be possible to generate the PIN using the SIM properties itself (assuming you have relation with the card vendor and the operator).
PIN = some_function(sim_properties)
Regarding each properties that you mentioned:
ICCID - yes, this unique per card. No read restriction and cannot be updated. First choice to use.
IMSI - unique per card but cannot be used. You need to provide PIN to read this file.
SPN - yes, can be used as well, but is not unique per card. If you want to use this file, ensure that it will not be updated by operator via OTA (Over The Air) RFM (Remote File Management).
GID - this file is optional, better not to use it.
For the function itself, I propose using cryptographic hash instead only hash, to give more security.
Additionally, you may also ask the card vendor to add additional proprietary file (EF), which you can put additional data inside (additional keys, bitmasks, key index of master keys to be used, etc).
At the final step, do not forget to convert the cryptographic hash result into numeric format 4-8 digits.
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.
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".
Could anyone explain to me in simple programmatic terms how these RSA key dongles work? I know Blizzard has them for WoW and paypal as well as some of the trading sites.
Thanks!
The fob has a clock and a serial number that is used as a seed for a PRNG. When you hit the "show me a code" button, the fob displays a number that is the product of that timestamp and the serial number run through the PRNG. The server knows your fob's serial number and time, and does the same operation. If your codes match, you're authenticated.
You can calculate the previous/next N values on the server end to account for clock skew.
Programmatic terms aren't necessary. Just imagine two pieces of hardware (your dongle and something at the company) that generate the same numbers at the same regularly scheduled intervals. It would be virtually impossible to guess what the number is due to some proprietary algorithms, so if the number you type in (or is automatically sent by the dongle) matches the number at the server, your identity is validated.
At least with the dongle I have, you also have to supply a pin known only by you and the server. So, in order to be authenticated you need both something physical and something in your head. That combination is pretty hard to fake. Even if someone gets the dongle, unless they know your pin it's worthless. And if they know your pin, that information is worthless without the dongle.
Security Now! episode 103 talks about how they work. (That link is to the show notes, but there's a link at the top of the page to the audio podcast.)
Basically, the key fob is synchronized with a server and they're both seeded to generate the same sequence of pseudo-random numbers. The server knows it's you if you input the right number at the right time.