in reply to Need a wait to generate a 4 digit "PIN" number

Actually, sending the three bits of data plus the PIN does not generate any extra security. Unless all this info is encrypted when sent, anyone listening in can capture the info and impersonate your users.

Furthermore, you are using "security through obfuscation". By not publishing your pin-generation code / algorithm, you hope that no-one who somehow finds the three bits of data will be able to "guess" the pin-code. But really it would not take a genius to guess the "join + MD5 or CRC hash" method. So don't rely on such amateurish security.

Actually, a secure link plus a user-id and password is sufficiently secure for most applications. The password is never stored on your system (so nobody can compromise the passwords even if they hack your database), just the result of a one-way trapdoor function (which is a function which has no inverse, so you cannot calculate the password from the result, other than by brute force).

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

  • Comment on Re: Need a wait to generate a 4 digit "PIN" number

Replies are listed 'Best First'.
Re^2: Need a wait to generate a 4 digit "PIN" number
by jaiello (Novice) on Dec 17, 2007 at 23:35 UTC
    The PIN is dynamically generated after concatenating the three elements. Two of which are guessable but the third is a pass phrase that should not be easily guessable. I agree. If they know all three elements, then the pin is irrelevant. The PIN is not really a PIN but a term I used for folks to quickly grasp what I needed to create. The checksum is merely a way for me to easily verify that the bits of data are the same ones used originally. I have a stateless machine. So, user A enters three bits-o-data. I create a checksum and send it to user B. User B still needs to enter the same three bits-o-data plus the checksum. Since I am stateless don't store anything on my system, I calculate the checksum and compare it to the entered PIN. If they are the same, I am relatively confident the three bits are the same. I can now proceed to the next task. If not, I simply say they are not the same so something they entered is different.
[reply]
Re^2: Need a wait to generate a 4 digit "PIN" number
by ikegami (Patriarch) on Dec 16, 2007 at 21:56 UTC

    But really it would not take a genius to guess the "join + MD5 or CRC hash" method. So don't rely on such amateurish security.

    That's why one of the joined fields should be some secret value. The key/password, so to speak. It should never be an issue whether the algorithm is public or not. Only the key needs to be private.

    But you do have a point. If the user already has a key/password, why would he need a PIN too? It's just another password. Two passwords are not more secure than one.

[reply]
      ikegami,
      Two passwords are not more secure than one.

      Well, when two pieces of information comprise a single password it can be more secure. For instance, certain facilities require:

      • Something you know (PIN)
      • Something you have (electronic badge)
      • Something you are (fingerprint or retina scan)

      I know this doesn't have a lot to do with the thread but when I read your reply I wanted to comment. A closer example would be one of those security token key chains which is constantly generating new passwords. When logging in, you must be looking at the currently generated password and add your pin to it to be authenticated. Having just the token isn't enough.

      Cheers - L~R

[reply]

        I was referring to passwords specifically. My statement about two passwords was not meant to be extrapolated to other pairings of credentials and shouldn't be extrapolated to other pairings of credentials. As you say, it doesn't necessarily hold up if you do.

        A closer example would be one of those security token key chains which is constantly generating new passwords.

        It's not having two passwords that makes it more secure, it's having the key chain and knowing password that makes it more secure.

[reply]
        Yes, but that are three different things: "knowing, having, being" and not three "bits of data plus a PIN" which are just the same type of things (all "knowing").

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]

In Section Seekers of Perl Wisdom