Where Does MD5 Go?

[justlukeyou]

Hi,

 

I hired someone to provide me with a subcription script from this forum and I am very dissapointed with the results.

 

There is:

 

No password masking (now sorted)

No forgotten password retrieval

No code to block pages which are not logged into

 

Also and more worringly the MD5 code is on the second page which someone tells me is wrong because 'packet sniffing' programmes can capture the password before it enters the MD5.

 

Can someone please confirm how a password system should properly be structured.  Should MD5 be on the login page?

[kenrbnsn]

To be as secure as possible on a login page, you should be using the https protocol with a certificate.

 

Ken

[justlukeyou]

Thanks,

 

Where can I get a code from which includes

 

MD5

password masking

code to block pages which are not logged into

[cunoodle2]

Hi,

I hired someone to provide me with a subcription script from this forum and I am very dissapointed with the results.

There is:

No password masking (now sorted)

No forgotten password retrieval

No code to block pages which are not logged into

One thing I can tell you is take this as a lesson learned.  NEXT time you hire someone to do a project spend some time and write out a DEFINED list of WHAT should be/not be included.  NEVER assume that anything is merely included as what you have in mind and what the developer has in mind are two completely different things.  For example on your next project start off with these items..

 

The system should have the ability for an EXISTING user to be able to reset their password.

Pages x.php, y.php and all pages in the directory "/var" can ONLY be accessed if a user is logged into the system by first going to "login.php"

IF a user is NOT logged in and they try to access pages x.php, y.php or any page in the directory "/var" the system should automatically redirect the user to index.php.

The system should use ONE WAY ENCRYPTION on the password in the mysql database.

 

Etc...

I've been on both sides of development and I can tell you the #1 most important thing is to have very very detailed specs.  This gives you a meticulous check list to go through at the end (payment time).  Otherwise just saying "I need a subcription script" could honestly mean a thousand different things.

[gizmola]

The security issue of pages, is typically handled via the use of php sessions.  There's no magic however... if you had an existing site which had no authentication/user system, and you pay someone to provide a "subscription" system, I wouldn't expect that those are two things that go together anymore than I'd expect that you'd have a password retrieval system built in. 

 

md5() is a hash routine.  It takes data as an input and does a 1-way hash that can not be retrieved, however md5 has been shown to have some issues, and in general fallen out of favor.  People use sha1 now as a frequent alternative.  With that said, when combined with a salt value, md5 does the main thing it needs to, which is to encode values, so they can not be turned back into plaintext.   

 

Without a salt there are tables of values that have been generated by people for all sorts of common words and names, so if someone is using "cat" as their password, a cracker with a table of values may be able to take the md5 data that you stored and determine some number of the values, simply by comparing the md5 hash they generated with the one you have.

 

A lot of things have to have gone wrong for this to be useful -- the person exploiting you needs to already have gotten access to your database and the password column, so in general many people still use md5 and it works adequately when a salt value is applied to the hash.

 

Now to put your mind at ease, the md5 calculation runs on the server.  When the username/password is gotten from a form it has to get to the server in some manner.  Forms typically use the post method.  Post takes all the data submitted and passes it from the workstation/browser of the user to the server.  The server can't run code on the user's workstation in advance... the input has to be submitted.

 

So the concern about sniffing will be an issue no matter what you do, unless you utilize https://.  How the person wrote their code, and where the md5() calculation is done is irrelevant when you consider that sniffing allows people to see any data that is on the shared network, so long as the sniffer is positioned in a place where the data will be passing by.  So if someone is using your site in NYC, and your server is in San Jose, anyone who is able to get a sniffer on any network between NYC and San Jose can see the data. 

 

An even greater threat than sniffing data these days is the interception of cookies used in sessions that allows someone to man-in-the middle by getting the session token and setting things up so that it looks to the server like you are the same user.

 

My point is that, there is no way to "code around" sniffing.  Realisticallly the biggest concern about sniffing comes from kids on college campuses or people using wifi.  These days, most people are connected to a switch, and there's no shared network to sniff at their point of entry, so most of the hubub about sniffing is based on wifi hotspots and people jumping on free wifi at their coffee house.

 

At the end of the day, only you can decide what steps you need to take, but there is a reason that your entire bank connection stays within https://.  There is a reason why gmail and other sites keep you in https://.  The only way you can guarantee that nobody has their session or password sniffed is to used https, and for the most part, those are configuration items that have to do with how your website is setup.

 

 

[justlukeyou]

I have added password masking, but the code to block pages and reset lost passwords sounds complicated.

 

Do you think its best to start again or just add these functions?

[gizmola]

There is no way to answer that in a vacuum.  If you are going to write the code yourself, you have to learn to understand how your system works, and the web environment seems easy to people because they can write html and get results, but it's actually very complicated and comes with a lot of complexity once you get beyond the surface level. 

 

PHP sessions are not hard. 

In your "protected page"

 

-you start the session

-check  if($_SESSION['authorized'] !== 1) {

  header('location: loginpage.....

  exit();

 

 

This can all be put in a small include file you require_once() at the top of any of your protected pages.

 

In your login script where the code returns that the person successfully logged in, you set $_SESSION['authorized'] = 1;

 

Of course for convenience you also probably want to put some more variables in the $_SESSION at login  time, like the user_id, and perhaps the username etc.

 

 

 

[justlukeyou]

Its probably I start again to be honest. 

 

I did get a log in system working by two tutorials together but it just wasn't reliable.

 

Can you quote me a price for a registration system covering all the points discussed?

 

I'm looking for one which is fully comprehensive, for example one I can include who the email is from.

 

I think the function is simply from: ?

[xylex]

First off, wrong forum to be asking for bids.

 

Secondly, you're making the same mistake you made the first time around.  Take a note from cunoodle's post and first sit down and write out everything you think a registration should do, not just say it should be "fully comprehensive" and expect that to mean anything to anyone. 

 

And if you're really concerned about maintainability and security, expect to spend a fair amount of money sourcing a reputable developer/firm with references if you're expecting to totally trust their judgement with these aspects.

[justlukeyou]

Thanks, I am a bit p****d off about because I got the code from someone with a PHPFreaks.com email address.

 

I did ask for email confirmation but it turns that you dont actually need to click the email link to get the login to work.

 

So basically could use someone elses email address to log into a site!!!

[gizmola]

Really an email confirmation system is a trivial addition.  I wouldn't rush to throw things out just because there's a feature that is missing.  Since you're heading that direction it seems, I'd point you to the freelance forum.

 

If you don't trust it, you might be better off, starting with the code, and asking for an assessment of it.  It might be poorly written code that will be hard to maintain, but it could also be solid code, that is a good basis for extending.

 

Since you started with a "subscription" system as your basis, again the problems that need to be solved for "subscription" like monthly billing and payment processing are not insignificant. 

 

There's really no good reason for you to be upset at this point about what you got previously, until you've gotten an expert opinion that the code is garbage and you really need to start over, but I'm sure you would admit that you're not able to decide that for yourself.  Get an expert to help you out with the problem.

[justlukeyou]

Thanks,

 

But the code didn't include password masking.  I'm sure that would be considered as implied.

 

I shall try again.

[cunoodle2]

Thanks,

But the code didn't include password masking.  I'm sure that would be considered as implied.

Again, lesson learned and I like your "I shall try again" attitude.  There is nothing you can do about the past so lets focus on the future here.  Next time write out a very very detailed check list like I have in my post above.  Again, I have been on both sides of the coin (paying someone to do the work vs being paid to do work) and I can tell you that detailed specs like I have listed (and every better add in some screen shots) is the ONLY way that works.  Otherwise it is luck of the draw.