| View previous topic - View next topic |
| Author |
Message |
Unknown
Moira's Silly Little Slave Bitch
Joined: 19 Jul 2005
Posts: 82
Location: Behind you...
|
 Posted: Wed Sep 21, 2005 7:06 pm Post subject: PHP |
[quote] |
|
I was trying to make a little login script for part of a web site i am working on but since i have NO idea on how to even start...(YES i searched google and since i really don't understand SQL I'm stuck) Is there ANY way to write a "SECURE" login script that uses ONLY php ???
ANY help/pointers/places to read tuterials will be VERY appreciated ;-)
_________________
Most people would succeed in small things if they were not troubled with such great ambitions.
|
|
| Back to top |
|
 |
DeveloperX
202192397
Joined: 04 May 2003
Posts: 1626
Location: Decatur, IL, USA
|
| Posted: Wed Sep 21, 2005 9:17 pm Post subject: Re: PHP |
[quote] |
|
| Unknown wrote: | I was trying to make a little login script for part of a web site i am working on but since i have NO idea on how to even start...(YES i searched google and since i really don't understand SQL I'm stuck) Is there ANY way to write a "SECURE" login script that uses ONLY php ???
ANY help/pointers/places to read tuterials will be VERY appreciated ;-) |
I'll send it to you by email dude.
_________________
Principal Software Architect
Rambling Indie Games, LLC
See my professional portfolio
|
|
| Back to top |
|
|
Nephilim
Mage
Joined: 20 Jun 2002
Posts: 414
|
|
| Back to top |
|
|
Unknown
Moira's Silly Little Slave Bitch
Joined: 19 Jul 2005
Posts: 82
Location: Behind you...
|
| Posted: Thu Sep 22, 2005 1:21 am Post subject: |
[quote] |
|
Nephilim---GREAT site thanks for the link ;-)
_________________
Most people would succeed in small things if they were not troubled with such great ambitions.
|
|
| Back to top |
|
|
LeoDraco
Demon Hunter
Joined: 24 Jun 2003
Posts: 584
Location: Riverside, South Cali
|
| Posted: Thu Sep 22, 2005 7:08 am Post subject: |
[quote] |
|
(This is based on the assumption --- which, as far as my researches into the matter have shown, is quite valid --- that Javascript does not have internal language support for encryption algorithms.)
Keep in mind that because you are, essentially, running a plaintext algorithm, and, even worse, are downloading it in plaintext from whatever server is hosting it to a remote local, there is no guarantee that a malicious attacker might not intercept the transmitted encryption algorithm and alter it with backdoors/etc. prior to passing it on to the remote location. While this is paranoid, if you are going to the trouble of attempting to encrypt passwords that are sent in plaintext over unsecure links, you're pretty paranoid already.
Also, you'll probably want to look up a JS implementation of SHA1, as it is more secure, supposedly, than the old MD5 hashes.
You'll probably want to look up SSL; if your server has support for it, it should be slightly more secure than any ad hoc solution manually built on top of open connections.
Finally, you might also consider adding an identifying hash value into any downloaded form content that is sent back to the server; the absence or modification of which should trigger some bells that the login information is not to be trusted. (Course, nothing would prevent a determined cracker from emulating this code, but, depending upon how suave the implementation is, it should keep out light-weight attacks.) If there is some sort of timeout value --- essentially, part of the data encoded in the hash --- this also prevents users on open terminals from hitting login pages in the history of a browser and resubmitting stored login data. While not perfect, certainly an interesting technique for helping in the security area.
Edit: Oh! And whatever you do: make sure that user passwords kept on the server are not kept in plaintext, and are encrypted with something like MD5. (SHA1 being the current preference.)
Edit: yet another thing to keep in mind: simply encrypting a users plaintext password, and sending that over the link with the username, is not a "secure" login system; essentially, if the encrypted password does not change for every login attempt, there is nothing preventing a malicious attacker from simply recording and replaying the login, without knowing anything more than the cipertext-password.
_________________
"...LeoDraco is a pompus git..." -- Mandrake
|
|
| Back to top |
|
|
Nephilim
Mage
Joined: 20 Jun 2002
Posts: 414
|
| Posted: Thu Sep 22, 2005 11:35 pm Post subject: |
[quote] |
|
| LeoDraco wrote: | | (This is based on the assumption --- which, as far as my researches into the matter have shown, is quite valid --- that Javascript does not have internal language support for encryption algorithms.) |
I don't believe it does.
| LeoDraco wrote: | | Keep in mind that because you are, essentially, running a plaintext algorithm, and, even worse, are downloading it in plaintext from whatever server is hosting it to a remote local, there is no guarantee that a malicious attacker might not intercept the transmitted encryption algorithm and alter it with backdoors/etc. prior to passing it on to the remote location. While this is paranoid, if you are going to the trouble of attempting to encrypt passwords that are sent in plaintext over unsecure links, you're pretty paranoid already. |
LeoDraco's correct. Any attempt to secure a login attempt based on anything other than the entire missive being encrypted is open to such an attack (and even then, if they can get through that encryption, you're still not safe). Of course, as LeoDraco mentioned, it's a step to keep out the casual attacker.
| LeoDraco wrote: | | Also, you'll probably want to look up a JS implementation of SHA1, as it is more secure, supposedly, than the old MD5 hashes. |
Good advice, although I'm not sure whether PHP does SHA1 or not - haven't looked into it. If it does, just replace the MD5 stuff with SHA1 stuff, and you get a stronger system.
| LeoDraco wrote: | | You'll probably want to look up SSL; if your server has support for it, it should be slightly more secure than any ad hoc solution manually built on top of open connections. |
Yeah, that's the ideal situation, because it helps defend against the back door attack LeoDraco mentioned earlier. Unfortunately, depending on your hosting situation, you don't always have that option.
As with all security measures, the key is to look at what you're trying to protect. If you're just trying to keep visitors from, say, seeing screenshots of your new game or something, and won't be devastated if they manage to get out, then you can probably get away with passwords in-the-clear and avoid all the hassle. The threat you have to respond to is only as big as the value of the information to you and the likelihood that someone would want to mess with it bad enough to devote a lot of time to doing it.
_________________
Visit the Sacraments web site to play the game and read articles about its development.
|
|
| Back to top |
|
|
LeoDraco
Demon Hunter
Joined: 24 Jun 2003
Posts: 584
Location: Riverside, South Cali
|
| Posted: Fri Sep 23, 2005 6:49 am Post subject: |
[quote] |
|
| Nephilim wrote: | | LeoDraco wrote: | | Also, you'll probably want to look up a JS implementation of SHA1, as it is more secure, supposedly, than the old MD5 hashes. |
Good advice, although I'm not sure whether PHP does SHA1 or not - haven't looked into it. If it does, just replace the MD5 stuff with SHA1 stuff, and you get a stronger system. |
Yeah, SHA1 has been supported since 4.3.0 (probably further back in CVS builds). The more recent MySQL distributions --- should, in fact, Unknown be using that variant --- have had support for it as well. Which means that you can push the computation of the hash to either the SQL or the PHP level. (Although, if you really are paranoid, you should only handle plaintext passwords in as few places as possible, and shred all memory that touches them afterwards.)
_________________
"...LeoDraco is a pompus git..." -- Mandrake
|
|
| Back to top |
|
|
Unknown
Moira's Silly Little Slave Bitch
Joined: 19 Jul 2005
Posts: 82
Location: Behind you...
|
| Posted: Sat Sep 24, 2005 4:10 am Post subject: |
[quote] |
|
Thnx's for all the help ;-)
If ya want to see what i've finally decided upon using for login Ect... goto Click to view login.php
login.php uses External files that contain MD5 hashed Passwords/Usernames...It takes input from the user, hashes it with md5 and then "cross-checks" it against those hashed Passwords/Usernames that are in the Extrenal files....
Anyone got any ideas on how to improve on it??
BTW if'n any a ya'll want ta source yer gona half ta contact Dev.x ;-)
_________________
Most people would succeed in small things if they were not troubled with such great ambitions.
|
|
| Back to top |
|
|
LeoDraco
Demon Hunter
Joined: 24 Jun 2003
Posts: 584
Location: Riverside, South Cali
|
| Posted: Sat Sep 24, 2005 9:33 am Post subject: |
[quote] |
|
| Unknown wrote: | login.php uses External files that contain MD5 hashed Passwords/Usernames...It takes input from the user, hashes it with md5 and then "cross-checks" it against those hashed Passwords/Usernames that are in the Extrenal files....
Anyone got any ideas on how to improve on it?? |
Again, as has been mentioned in this thread, this all depends on exactly how important the data is that you are attempting to protect. What also matters is if your question is more towards implementation --- i.e., things that you can do in PHP et al to improve the system --- or more towards authentication design.
Should your question be referring to the former:
- By "External files," I assume you are referring to a set of plaintext --- that is, unencrypted --- files, each of which contains a tuple containing, at the least, the user's name and password (which, if I have your description correct, has been encrypted); while this solution is fine, it isn't terribly sophisticated. There are a number of ways in which this can be cleaned:
- UNIX, and many of its derivative variants, store information about all users in a central, flatfile database, most commonly in /etc/passwd; in general, this file has a line per user, with each line representing a tuple of data, of which the user's name and password are kept. So, if you are utilizing multiple files, you can probably cut down some system overhead by condensing everything into a single file, and utilize some byte-value to differentiate the tuples.
- A better decision --- at least, in terms of whom does the bookkeeping --- would be to utilize a DBMS, such as MySQL or PostgreSQL, to do everything for you. While there are a variety of different DBMS', relational databases are quite popular, and SQL is pretty much the de facto standard, when it comes to query languages. (The two DBMS' that I linked to, by the way, are free/open-source, and are often packaged with most Linux distros these days, so aquisition should not be a difficulty.) Then, you would only need to define a table or two --- depending upon what you want to do --- and write a few queries here or there to handle things for you. PHP has language bindings for most popular databases, as can be seen at the online manual. (MySQL and PostgreSQL bindings.) Also, there is an utterly fantastic PEAR package, Database, which acts as a wrapper for most systems, and is very easy to use.
- Again, as mentioned all over the place in this thread, MD5 has been deemed, in most security circles, to be breakable, and, at the least, not as secure as it once was. So, you should probably prefer to do things with SHA1, whose PHP implementation has already been linked. (Although, SHA1 has, apparently, some security flaws; SHA2 would, obviously, be the preferred algorithm to go with, but PHP seems to not have an implementation, yet.)
- While this is more on the authentication design protocol side of things, keep in mind that your users will be, with your current system, sending things in the clear over an unsecure link, which opens a variety of exploitable loopholes in your system. While the JS alternative is not wonderful, it is slightly more secure than sending plain-text over the link.
Now! On to some authentication protocol issues:
- If you elect to implement a /etc/passwd like flatfile, keep in mind that unless you restrict access to the file, or encrypt it --- neither of which is really securing the file from the dedicated attacker --- anyone who wants can inspect it; while, in the best case, the passwords are encrypted, it is not enough to simply store the MD5/SHA1 hashes alone. Take, for example, the case where two users, Alice and Bob, both have the password, "marlin;" in the naive scheme, the hash of "marlin" (which is "0fe74481e67876a75541e5341659839104a44b11") will be stored in the flatfile, be viewable to everyone, and, worst of all, will be the same for both users. Which means, Carol --- some other user who gains access to the passwords file --- will notice that both Alice and Bob have the same password; if she were to break that password, she'll have twice the opportunity to reak havok on the system.
All is not lost, though: enter salts; a [url=http://en.wikipedia.org/wiki/Salt_(cryptography)]salt[/url] is some random string which, upon concatenation to a password, causes the hash of the password to be perturbed. (As "good" hash functions, such as SHA1, will generate entirely different hashes for slight variations, this is a good thing.) So! A better solution would be to store, in the user's tuple, the name, the salt, and the encrypted password/salt combination. (This is fairly secure: as long as the encryption is hard to break --- which it should be --- and as long as the password is "good" --- i.e., something that would take entirely too much time to generate, even with a brute-force search --- revealing the salt adds no new information to the attacker about the ciphertext; as SHA1 hashes are all the same length, anyway, appending a few more characters does not matter at all.)
- Encryption, it should be kept in mind, forms a cornerstone of a secure system, but, by itself, it hardly makes the system any more secure than if everything was plaintext. Again, it matters how valuable the data is that you are attempting to secure. So, assuming you want some sort of uber-security, you will need to up the ante on your authentication protocol. For example, take a look at the protocol for Kerberos; what you will notice is that it isn't simply a case of a user submitting a name/password pair. The handshake is prolonged, and composed of a series of encrypted steps, each of which with a specific goal in mind. (It should also be noticed that Alice, while holding data that eventually gets passed to Bob, can never access that data --- at least, the presumption runs, not in a timely manner.) (Kerberos, though, is a bit too much for a simple web-login application, and, really, serves a much different venue of communication between online parties. Which is not to say that it cannot be used for web-site applications; it might not be terribly practical to do so.)
- Edit: if you do decide to utilize a JS implementation of a cryptographic hash function (such as MD5 or SHA1), again, it would be useful if you perturbed the hash for each login attempt in a way that is replicable on the servers side; this way, recorded encrypted passwords have very limited use.
Whew! I could probably write more on the subject, but that should be enough to get going on some simple systems.
You might also be interested in looking up the basis for a few of the encryption methods employed by different modern systems; for instance, discrete logarithms are used in a few different protocols, and are rather sexy to know. One-time passwords are at a bit higher level, but are also rather fascinating. Also, modular arithmetic has to be mentioned, as it is the basis for RSA.
(Heh: although, again, all of that is not, strictly speaking, immediately applicable to securing a simple web-site. However, it is all good to know, and is utterly fascinating.)
_________________
"...LeoDraco is a pompus git..." -- Mandrake
|
|
| Back to top |
|
|
Unknown
Moira's Silly Little Slave Bitch
Joined: 19 Jul 2005
Posts: 82
Location: Behind you...
|
| Posted: Sat Sep 24, 2005 1:50 pm Post subject: |
[quote] |
|
Holy crud dude thats a ton of info... I'll be reading for awhile.... ;-)
Check out this little script ;-)
this is sorta a one time password but....not very secure because you can get in by viewing the source and doing some counting on your fingers ;-) heck ,you can even write a "decyrption" program in bout 5-10 min after viewing the source ;-)
but heck it was fun to code!!!
BTW...all the users passwords are stored in one file and all the users names are stored in another file http://ccps.rpgdx.net/jeff/files/pass.txt
http://ccps.rpgdx.net/jeff/files/user.txt
_________________
Most people would succeed in small things if they were not troubled with such great ambitions.
|
|
| Back to top |
|
|
Unknown
Moira's Silly Little Slave Bitch
Joined: 19 Jul 2005
Posts: 82
Location: Behind you...
|
| Posted: Mon Sep 26, 2005 1:54 am Post subject: |
[quote] |
|
So....Does anyone no how to implement SHA-2 With PHP ???
_________________
Most people would succeed in small things if they were not troubled with such great ambitions.
|
|
| Back to top |
|
|
LeoDraco
Demon Hunter
Joined: 24 Jun 2003
Posts: 584
Location: Riverside, South Cali
|
| Posted: Mon Sep 26, 2005 6:28 am Post subject: |
[quote] |
|
| Unknown wrote: | | So....Does anyone no how to implement SHA-2 With PHP ??? |
You can get a description of the algorithm at the article on SHA over at wikipedia; should be rather simple to transcribe it.
That said, there are two good reasons not to implement SHA2, and use PHP's implementation of SHA1: first, the complexity of the known attacks against SHA1 are massive, so, unless you are protecting government secrets, you would be giving yourself a needless headache to prevent something that, quite likely, will not happen; second, PHP's SHA1 implementation is, unless I'm mistaken, validated to be an accurate implementation, whereas you would have no assurance that your homebrew implementation of SHA1 is valid.
_________________
"...LeoDraco is a pompus git..." -- Mandrake
|
|
| Back to top |
|
|
DeveloperX
202192397
Joined: 04 May 2003
Posts: 1626
Location: Decatur, IL, USA
|
| Posted: Mon Sep 26, 2005 9:16 am Post subject: |
[quote] |
|
| Unknown wrote: | Holy crud dude thats a ton of info... I'll be reading for awhile.... ;-)
Check out this little script ;-)
this is sorta a one time password but....not very secure because you can get in by viewing the source and doing some counting on your fingers ;-) heck ,you can even write a "decyrption" program in bout 5-10 min after viewing the source ;-)
but heck it was fun to code!!!
BTW...all the users passwords are stored in one file and all the users names are stored in another file http://ccps.rpgdx.net/jeff/files/pass.txt
http://ccps.rpgdx.net/jeff/files/user.txt |
uhm, gee jeff...you're not too bright here. :P
STOP POSTING LINKS TO THE FILES.
You are wasting your time, and also rendering your efforts useless.
Giving someone the md5 hashed files, is as good as giving the text.
damn, dont post anymore links to files on my site.
thanks.
email me if you have questions.
_________________
Principal Software Architect
Rambling Indie Games, LLC
See my professional portfolio
|
|
| Back to top |
|
|
LeoDraco
Demon Hunter
Joined: 24 Jun 2003
Posts: 584
Location: Riverside, South Cali
|
| Posted: Tue Sep 27, 2005 6:19 am Post subject: |
[quote] |
|
| DeveloperX wrote: | uhm, gee jeff...you're not too bright here. :P
STOP POSTING LINKS TO THE FILES.
You are wasting your time, and also rendering your efforts useless.
Giving someone the md5 hashed files, is as good as giving the text.
damn, dont post anymore links to files on my site.
thanks.
email me if you have questions. |
That's not entirely true; as I mentioned in one of my posts, the UNIX passwd file is, unless the sys-admin is uber paranoid, publically available. Security through obscurity is never going to protect a system in any case; anyone who wants that data bad enough will find it no matter how well hidden it is. That said, giving out the hashes to play around with isn't a terribly fantastic idea, but, depending upon how secure the encryption algorithm is, and upon the data actually hashed, seeing ciphertext out of context does not really help an attacker a terrible amount.
_________________
"...LeoDraco is a pompus git..." -- Mandrake
|
|
| Back to top |
|
|
Unknown
Moira's Silly Little Slave Bitch
Joined: 19 Jul 2005
Posts: 82
Location: Behind you...
|
| Posted: Fri Sep 30, 2005 12:59 am Post subject: |
[quote] |
|
;-) sorry DEv.X I wont link ANY more files.....
BTW....when i said but heck it was fun to code!!! I meant
but heck it was fun to MOD!!! Dev.X coded the main part for me ;-)
_________________
Most people would succeed in small things if they were not troubled with such great ambitions.
|
|
| Back to top |
|
|
  |
Page 1 of 2 |
All times are GMT
Goto page 1, 2 Next
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
