C++ loop help

Discussion in 'Mac Programming' started by chordate68, Apr 25, 2008.

  1. chordate68 macrumors regular

    chordate68

    Joined:
    Oct 16, 2007
    Location:
    Los Angeles
    #1
    Hello,

    I am trying to write a loop for the pin number for the atm project I am working on. I need the pin to be 111 and the number of pin attempts can only be three, after that the program has to quit. If anyone can offer ant suggestions or help it would be much appreciated.

    thanks!
     
  2. Eraserhead macrumors G4

    Eraserhead

    Joined:
    Nov 3, 2005
    Location:
    UK
    #2
    I assume this is a school/university project?

    You need to count the loops to make sure there are only three and check the inputed pin against the stored pin number each time. You then call a "success" method if the attempt succeeds.
     
  3. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #3
    I would define two variables, logonSuccessful and numAttempts. Set both to 0 outside the loop. Have your loop condition be logonSuccessful == 0 && numAttempts < 3. Read from stdin, and use strcmp to compare the entered value to your valid pin(s). If the correct pin is entered, set logonSuccessful to 1. Otherwise, print a message stating that the incorrect pin was entered, and if you want the number of remaining tries. Increment numAttempts.

    When the loop exits, if logonSuccessful is 1, they entered the pin correctly. Otherwise they exhausted their attempts. You can then act accordingly (i.e. keep the card, shred it, etc. if they failed, prompt them to make a deposit/withdrawl if they succeeded).

    -Lee
     
  4. Eraserhead macrumors G4

    Eraserhead

    Joined:
    Nov 3, 2005
    Location:
    UK
    #4
    ^^ That's good advice. Though it may not be required for this project you should set the maximum number of attempts as a global constant so the code can easily be reused.
     
  5. Sander macrumors 6502

    Joined:
    Apr 24, 2008
    #5
    - Keep track of the number of tries so far
    - If it exceeds the maximum allowed number, display a message and quit
    - If the PIN matches, break the loop
    - Make sure to check for "off-by-one" mistakes, so you don't accidentally allow only 2 or up to 4 retries.

    Sorry for not providing direct code, but this sounds like a homework assignment.
     
  6. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #6
    Good point. If this were real and not a project/toy app I would say that you should get the encrypted PIN and salt used to generate it per account from a DB, then encrypt what is entered with the salt, and compare. The number of failed attempts could also be kept in the DB along with the maximum number of attempts (either a global setting in the DB, or perhaps a per account setting, if needed). That way you can track failed attempts across sessions/devices. On success the number failed will be reset to 0. There could be an interval stored in the database upon which the failed attempts are set back to 0, but that would require storing the timestamp of the first failed attempt. I'd probably want this done by a database trigger that checks if failed attempts is 1, if so this timestamp is set to now(). When failed attempts is 0, this could set the timestamp to null.

    Obviously all this is outside of the scope, but it's good to broaden your horizons sometimes.

    -Lee
     
  7. lazydog macrumors 6502a

    Joined:
    Sep 3, 2005
    Location:
    Cramlington, UK
    #7
    I think the PIN entered at the ATM is encrypted and sent to the host computer for verification. Sending the PIN to the ATM, even if encrypted, would be insecure imho.

    b e n
     
  8. Gelfin macrumors 68020

    Gelfin

    Joined:
    Sep 18, 2001
    Location:
    Denver, CO
    #8
    There are well-known techniques for making such a communication secure.

    EDIT: Never mind. I see what you are saying. I thought you were talking about the security of the communications channel. You are correct that authentication should not be performed on the client.
     

Share This Page