need for a login script - Programmers Heaven

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

need for a login script

abhinav2471abhinav2471 Posts: 13Member
Is anybody aware of scripts for login providing adequate security.
if not the script please guide me in this line as i have to make a site providing login facility
please it is urgent

Comments

  • JonathanJonathan Posts: 2,914Member
    : Is anybody aware of scripts for login providing adequate security.
    : if not the script please guide me in this line as i have to make a
    : site providing login facility
    : please it is urgent
    :
    For existing scripts check:-
    http://www.cgi-resources.com/

    You're a lot too vague in your question. How do you define "adequete security"? That depends entirely on the situation. Also what is it that you need to protect access to?

    Jonathan

    ###
    for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
    (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
    /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

  • WeirdofreakWeirdofreak Posts: 439Member
    In general, you'll want the usernames and passwords stored in a file, or a database. Encrypt the passwords using something like MD5 (I'm pretty sure there's a Perl module, somewhere), and when somebody gives you a un/pass, convert the pass they give via MD5, and compare it to the existing one for that username. If they match, let them in, if not, don't.

    If you use a database, be sure to guard against SQL injection. If you don't, somebody can just type in a real UN for the username, and for the password type:
    ' OR 1 = 1 OR '' = '
    (including quotes), and the parser will interpret the commands literally, letting them in if either the real password is a blank string, or the input password is a blank string, or 1 is equal to 1. The second is never true, the first should never be true, but the third is always true. If you escape out quotes, you shouldn't have a problem. I think. It would probably be best to disallow all characters apart from letters, numbers and underscores, and easier as well.

    Be sure to give the password file an obscure name, because if they get hold of it, the passwords can be brute-forced with a dictionary. You could also add a number to the beginning/end of every password before encryption so that that approach won't work. They'll still be able to reverse-engineer it though, with difficulty.
  • JonathanJonathan Posts: 2,914Member
    : In general, you'll want the usernames and passwords stored in a
    : file, or a database. Encrypt the passwords using something like MD5
    : (I'm pretty sure there's a Perl module, somewhere),
    Yup, more info here:-
    http://search.cpan.org/~gaas/Digest-MD5-2.33/MD5.pm
    If you don't want to use an external library, there is always the crypt() function that's built in to Perl, though do be aware that it is mapped onto the system's crypt() function and therefore cannot be relied on for cross-platform stuff.

    : and when somebody gives you a un/pass, convert the pass they give
    : via MD5, and compare it to the existing one for that username. If
    : they match, let them in, if not, don't.
    :
    If you are using a (MySQL?) database rather than a flat file, don't bother with Perl's MD5 module - just use the MD5 function built in to MySQL. It'll probably be faster.

    : If you use a database, be sure to guard against SQL injection. If
    : you don't, somebody can just type in a real UN for the username, and
    : for the password type:
    : ' OR 1 = 1 OR '' = '
    : (including quotes), and the parser will interpret the commands
    : literally, letting them in if either the real password is a blank
    : string, or the input password is a blank string, or 1 is equal to 1.
    : The second is never true, the first should never be true, but the
    : third is always true. If you escape out quotes, you shouldn't have a
    : problem. I think. It would probably be best to disallow all
    : characters apart from letters, numbers and underscores, and easier
    : as well.
    Very sound advice. There is more info on this available here:-
    http://www.jwcs.net/~jonathan/cgisecurity.htm
    I generally escape all quotes. There are more subtle SQL injection tricks you can try - I'm still waiting to try my escape'n'comment idea, e.g.

    SELECT userlevel FROM users
    WHERE username = '$username' AND password = '$password'

    Here if only quotes are escaped, I could set $username to "somejunk" and $password to " OR 1 #". That would result in:-

    SELECT userlevel FROM users
    WHERE username = 'somejunk' AND password = ' OR 1 #'

    Where # is the comment symbol (I think). It all hinges on whether the commenting out can be made to work. The quote escape most probably can. This is also why to escpae to something like a HTML character code style thing, not a ' - otherwise someone only needs an extra backslash in the right place (before their quote). Careful checking could eliminate that, of course.

    : Be sure to give the password file an obscure name, because if they
    : get hold of it, the passwords can be brute-forced with a dictionary.
    Obscurity is not a security technique. It's just obscure. :-)

    : You could also add a number to the beginning/end of every password
    : before encryption so that that approach won't work. They'll still be
    : able to reverse-engineer it though, with difficulty.
    :
    If they manage to swipe your password file, they can probably swipe your code; then this mechanism would last all of 5 minutes. Of course, if it's in a database then they could steal that without stealing the code and maybe that would be a good idea after all. It all depends on access to the code itself. But I'm still of the belief that things that are truly secure are things where revealing the source code doesn't damage the security of the system.

    Jonathan

    ###
    for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
    (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
    /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

Sign In or Register to comment.