Thread: Password Checker

  1. #1
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853

    Password Checker

    I was mostly wondering, not that I will do such a thing. Lets say you want to make a simple program that asks for a password, you enter it, if correct it launches an application. My question is what security factors will you have to think of? Lets say the code is like this:
    Code:
    <iostream>
    using namespace std;
    
    #define PASS "hey"
    
    int main(void)
    {
       string str;  
       cin >> str;
       cin.ignore();
       if (str == PASS)
             system(something);
    }
    How could somebody try to hack the program? If he has access lets say to the .exe file, under windows. What security measures could you take in order for a simple password checker program to be safe?

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    If all your program does is a system call, why can't the "hacker" make this system call without your program?
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > How could somebody try to hack the program?
    1. Do a hex dump of the .exe, and see the string "hey"
    2. Run the code in a debugger, stop at the string comparison, and change BEQ into BNE. In other words, any incorrect guess is success.

    > What security measures could you take in order for a simple password checker program to be safe?
    None?
    Sure you can raise the bar a little to hamper "curious noob", but if someone wants it enough, they'll get it.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  4. #4
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Encrypt the password in the file and encrypt the password entered. That will raise the bar for anyone trying to crack it.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #5
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    Encryption is good, but someone can just check the encryptor/decryptor method/program, right?
    Is there a way not to be able to view an .exe file, so no hex dumb? Be able just to execute it? Of course then somebody could "look" into the main memory where it is loaded I guess.

    In any case, what is generally a good method to make such a program? Does this concerns more "OS security", thus protecting files and stuff, or the actual code of the program will make it safer and more hard to crack?

  6. #6
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Assume that the opponent has everything except the key. Even to the point of you giving them the source code.

    exe packers and encrypters just make it harder.
    Relying on the OS to make an executable "execute only", which will stop a number of people as well. But again, if your opponent is admin/root on their own machine, you're still not much better off.

    Obfuscation and hiding don't work for real security.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Let's look at Linux's su program. su is installed for root as suid, which means it will run with root privileges no matter who calls it. It then queries the user for the root password and if it matches, launches a shell running as root.

    Venues of attack:
    1) Search the executable for the password. You can't do this, because the password is in the authentication mechanism's password store, not in the executable. For the traditional shadow pwdb, this is the file /etc/shadow. You cannot read this file, since it's readable only by root.
    2) Modify the executable to not check the password. The executable is only writeable by root, so you can't do this.
    3) Attach a debugger and change the code at runtime. You can't attach a debugger to a process running with higher privileges than you.

    Thus, su is secure against cracking.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #8
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    Okay, I get your points. So it has mostly to do with the OS than "programming in a safe way", so I guess this hasn't much to do with C++ programming, so I might move the subject in a more appropriate place. Thanks

  9. #9
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    It has a lot to do with how you write your program, certainly.

    For example, even doing an MD5 of the input, and compare it to a pre-MD5'ed version of the password is more secure. Though it may be a sluggish way of encrypting a password depending on length.

    Using a system() call is nearly always a security flaw. The only way around this is to call an exact path. However, the means used to determine exact paths are always platform specific enough that one could typically also use a platform specific means by which to spawn a new process.

    Cornedbee is demonstrating a secure program. By no means does that mean that you have to be running *nix to have security (though I will debate many who argue otherwise). Even on windows you can make an honest effort at securing your data. In my experience, it is almost universally better to never allow a user direct access to any of the data that is used for comparison. I.e. have an offsite host that does password checks. Though this may not always be possible or even reasonable, I like this approach. But even doing this means at some point your data is sent and again vulnerable.... Its not easy dude. That is why there is money in security.

  10. #10
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    First of all, use a hash of the password, rather than a password itself. That is, find a non reversible algorithm that you can apply to the password that will yield a unique enough result. Java's string hashCode algorithm is sufficient. This is a minimum. Don't ever store passwords, its not safe, and there's no point given the alternative.

    Second, system calls are simply not safe. It is usually possible to see what system calls were made and repeat them. Alternately a process can be made to run in a modified environment that will trace the system call. Even if you manage to hide the system call, the fact is that the program still does not prevent somebody from from trying to guess at the system call directly, circumventing the call.

    If you want you program to be the only access point to whatever other program you are indirectly calling, you need to somehow make that program dependent on yours. If you do not have access to the program source, then the only way to do this is to encrypt that program. Encryption will ensure that only your program can decrypt the target.

    But you can't just hide the decryption key in your program, because then somebody can just read the executable and get it. You have to make it dependent on the password. But this adds vulnerability because your short password is too simple to encrypt large amounts of predictable data.

    So even after all that work, your program would still be vulnerable, and more vulnerable then may at first be guessed.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  11. #11
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    I have had to remake code by disassembling a program before. Yeah its work, and no it isn't fun. If I can do that in order to get the basic jist of my code so I can rewrite it, what makes you think someone more savvy with disassembly cannot just reverse engineer your entire program?

    I know that sometimes these things sound rediculously unlikely enough that you would not even consider them. Sometimes you have to make considerations for the 0.00001&#37; of the population that will do something highly ambitious with your programs.

  12. #12
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    The bottom line is - you just can't make a program safe from everything. Yes, you can take precautions, but there will always be someone who can hack your program.
    A very good example of this is DRM. They create them to very difficult to get around or reverse engineer, yet people do crack them.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    You can't make data or a program safe if the cracker has physical access to the machine on which it resides. At some level of technical understanding, it's always possible to crack the security. This is the problem DRM faces. It tries to restrict the abilities of the person who has the protected data in his hands. It goes to absurd lengths for that. But it all relies on somehow hiding a key from the user, and that's just not possible in the long run.

    Now, securing something over a network is possible and considerably easier. Security holes over the network are always shortcomings of the programmer, be it in design or implementation of the software.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  14. #14
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    > Security holes over the network are always shortcomings of the programmer, be it in design or implementation of the software.

    Beautiful. That is my thinking about this subject too. Though even one way hashes that are sent over a network still suffer potential cracking by someone with direct access to the program executing the algorithm. Granted it takes some disassembling genious. But where there is a will... there is a way.

  15. #15
    3735928559
    Join Date
    Mar 2008
    Location
    RTP
    Posts
    838
    check out md5

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. A tenet connection from a C program..
    By ahmd2080 in forum Linux Programming
    Replies: 2
    Last Post: 07-04-2009, 03:42 AM
  2. Problem reading a password from a file.
    By medeshago in forum C Programming
    Replies: 15
    Last Post: 12-21-2008, 07:20 AM
  3. [Q]Hide Password
    By Yuri in forum C++ Programming
    Replies: 14
    Last Post: 03-02-2006, 03:42 AM
  4. written command line password generator
    By lepricaun in forum C Programming
    Replies: 15
    Last Post: 08-17-2004, 08:42 PM
  5. password
    By hammers6 in forum C Programming
    Replies: 1
    Last Post: 10-10-2001, 12:14 AM