View Full Version : making your site secure...

01-05-2004, 03:19 AM
i dont know if i put this in the right forum, but i want to secure my sign up page (on my web site). how can i do it. i know that ssl, or https, does the job, as my friend said, but i dont know what exactly this is...

01-05-2004, 06:19 AM
Well even with ssl, that doesn't mean your site is secure. It's all down to how your code is written. Sloppy code won't make the site secure, no matter what you stick on top of it.

01-05-2004, 06:36 AM
Okay. Well, my Sign-Up page on my web site is a PHP page (signup.php), where people give information such as their name and credit card numbers. Is there some way I may put atleast some kind of security like people do?

01-05-2004, 09:59 AM
Well, i think that the most importat things are:
a. learn how internetcommunication works
b. keep the big picture in mind.

The signup page itself is easy, because there's nothing intresting there. Just some PHP code that could at the most give away which hashingalgoritme you use. The weakest link and biggest problem is how to get the data from the client to your server without that anyone will be able to intercept it.
SSL will pretty much cover that. It's not buletproof of coarse, but the dangers mainly lie at unsavy users. But SSL prutty much wraps it it up.
It will encode all data that is sent from and to the client + it ads some authentication.
Encoding: each datapackage gets encoded using a sessionkey. That is a key which is generated when the client connects to the server the first time (well, second time), and that is only used for that session. So even if someone intercepts the message, he will need to take some effort to get to the actual message. But it's not impossible ...
It is however, virtually impossible to alter the content of the sent package, because the length and some other message-specifications are incorporated and added to the content, before it gets encoded. And changing the content will produce an error when the message is decoded (by the server or client). So the encodeing part of SSL ensures the messages integrity + offers some protection that third partys can't read your message.
Authentication: SSL keeps track of which user send a request. TCP/IP is a stateless protocal. There isn't a persistent connection between client and user. So the server doesn't actually knows who sends the request and which previous requests he's sent. It knows the IP and will send a response to that IP. So all server side language (like PHP) use sessions to keep track of their users. SSL adds some extra's to this + supports Kerberos (an authorisation system that sends quickly expiring tickets to a client and the server, which gives that client permissions to request a specific file on the server and which at the same time notifyes that server that that client has permission for that file). So the authentication part is supposed to identify the client that sends a request and with Kerberos, you can ensurethat that identified client has permission for that request.
But everything can be bypassed. If you've read carefully, then you'll notice that everything is sent over the web. So everything is interceptable.
But there are much easier ways to exploit this sort of security. The most popular is just imposing yourself as the real site. Setting up a fake idetical loginscreen, placing yourself between client and server and letting pass alltrafic over your server etc (Note: authentication doesn't mean that you can verify who exactly started the session. It's like when a secretary dials the number and request the call, and that the manager then takes over. You'll never know who actually made the call...
It's easier for the client to detect such fraud, but most of them will only look if the 'lock'-icon is closed (and anyone can get a certificat these days))

Bulletproof encodeing will always require that you use another medium (post or so) to send a device or piece of software, that will generate the session-key. But that might be overkill. When e-commerce started, there were some initiatifs (Compaq or IBM, i believe) to send a unique processor-number with each request, but privacy concerns put a stop to that. It will however probably always be the most secure way to identify a client.

The bigger picture: the datatransfer can probably be sufficiently secured using SSL. But then you have the data and you need to store them + you can only give access to the rightfull owner.
First question: why store their creditcardnumbers? Since it is a signup-page, their is no real need to do that there. You can just as well request and store them when they first log in. Or why store them at all? Are you sure you can store them sufficiently secured that noone can access them? And are you sure, that you can make your login tight enough so that noone can impose himself as the real client and log in with his user and pwd ? Or that your sessions can't be hijacks?
And what will you use them for? Just to automatically fill them in for the user on later visits? Or as extra authentication? (--> your passwords should be strong enough to notrequire this)
Are you willing to take such risks just to offer that tiny bit of service?

I would recommend that you use a payment merchant to handle your payments, so that you don't need to take the risks and extra securitymeasures (which will never be costeffective). You just take an account there and they take care of validating creditcardnumbers etc and return you a OK or not OK about the payment. I's day "stick to your core-business" and "don't get envolved in such risky business unless it will offer substantial extra profit".
So in short: solve your problem by buying a sollution and let other people deal with the risks.

01-05-2004, 12:38 PM
wow raf! that's what I call a great post :thumbsup:.
I was wondering about a security issue: even with hash, encryption SSl and whatever you can't prevent your users to download 'risky' files and having a trojan installed on their comp. One of the common use of a trojan is what is called a key loger that let the hacker see everything that you type on your keyboard. Is their a way to prevent it or not? It is obviously not a security issue about your own site but I was wondering if there is a trick that could counter this kind of hacking...

01-05-2004, 01:56 PM
wow raf! that's what I call a great post
Well thank you. Glad my time wasn't completely wasted :)

I was wondering about a security issue: even with hash, encryption SSl and whatever you can't prevent your users to download 'risky' files and having a trojan installed on their comp. One of the common use of a trojan is what is called a key loger that let the hacker see everything that you type on your keyboard. Is their a way to prevent it or not?
Yes. If you read my post carefully, then you'll see that the only bulletproof authenticationmethods will always envolve some hardware (like the CPU-identificationcode) or some hard or software that generates a new sessionkey each time you log on. This sessionkey is the actual pwd. So even if a hacker gets the key you used at a certain datetime, it will be useless to him because he can't start a new session with it.
I know of a bank where you need to get a floppy disk that stores a keygenerator on your computer. You can only istall it on one machine and it computes your entrycode (after you entred a pincode) and sends it to the server. So even if you would steal the disk or the complete harddrive + get the users pincode, it would probably still be worthless. My bank uses a piece of hardware (digipass. looks like a pocket-calculator) where i enter my secret pincode, and it then generates the entrycode that i need to type over. So you'd need to install a webcam + steal my digipass to use my account. (but i would be worth it !)
A less exotic but effective way, is to send the user a 'token' (you can mail it or post it or send him a pigeon or ...). It's just a numbered list of random strings. When you log in, you need to enter 'token 12' or so within x seconds.
So even with a key loger, it would take quit a while until the hacker would have a fair amount of tokens and be able to log in. And you could make that very strict. Like only allow one trial to enter the token, and then request another one + printing a message that the previous token was wrong (regardless of when it was entered) and that they need to click a link or so if he/she didn't enter the incorrect token etc.
So it's a very cheap method to make your app much more secure. The belgian e-governament works like that. You could for instance also only use it for 'special' actions and only ask for it then. Like if the user want's to change his pwd or so.

It is obviously not a security issue about your own site but I was wondering if there is a trick that could counter this kind of hacking...
Well, it's not because the user messed up, that you can't be blamed. Specially not if he gets administrator (someone you have some tiny responsability over?) access or so, and starts manipulating or abusing other clients accounts. It may sound unfare but there will probably always be a client that can find something you could have done to detect that someone was abusing his account. And besides possible legal actions against you, there is also a lott of image damage. Even if it turns out that the client was to blame.
The by far most weakest link will probably always be the clients careless behaviour. Not having a firewall, not frequently or effectively scanning for virusses and spyware, simply mailing there pwd or telling it over the phone to a supposed administrator or helpdesk, keying it in on a bogus 'renew your account' webpage (you'd be surprised ...), always using the same pwd, not checking adresses, ...
So i think that you need to agree on a strict security policy (even if it's just to cover your make sure your out of the fireline) + strong or dynamicaly generated session-passwords + make him/her sign or agree that the securitymeasures you took are sufficient (my bank did that, so i signed. i'm so stupid at times :)) + make it as tight as possible or as tight as the clients accepts it to be, because it always costs developmenttime and can make the app less userfriendly .
For instance: if you only expect american IP's, well then your authentication should look up the IP's location (there are free db's out there with IP to Country tables) and ban all non american IP's. Which is bad luck for Georgie Boy if he wants to log in from Irak or so. (But you could combine this with the 'token' system where he can set a period that he will be using this ISP and comfirms it by entering token x etc). Or you could register the country or even ISP if he registers and then on each login checkif it's the same. IP's can be spoofed etc, but it all helps.
You could require your users to have cookies enabled and only set a cookie on their accounts activation (first login). And then only allow people to log in if they have that cookie set. Else they need to reactivate using the token etc.
Cookies can be stolen, true, but if you do all these things, it becomes harder and harder. And since most abuses or done by scriptkidies with a downloaded cracker-toy or people that simply exploit known security-issues, there i a good chance that they wount have the motivation or ability to look for openings at your end or at the clients end.
So even if you have the pwd, i could make it very hard for you to get in. And you would probably choose to hack my host instead of breaking in through my login-form.

I think that the best way to make your logins more secure with a maximum of usercomfort is sharing your code and asking for pear reviews. But this obviously can't be in a public forum since you'll probably be uncovering weaknesses where lotts of other systems soffer from... and the true hacker is never far behind (if at all) in coding skills (--> i'm not trying to create a romantic or glorifying atmosfere towards hacking).

01-05-2004, 02:47 PM
thank you very much raf and thanx for the time you took to post this answer.... that was very enlightening to me!


01-06-2004, 04:18 PM
Wow, raf in writing mode... gotta have to read this a second time.

Anyway, jeskel, you asked for a method to prevent key loggers detecting what secret numbers (PIN, TAN, etc.) the user typed. My bank does this in their online accounts: You have 10 images representing the decimal system, and you can use these similar to a calculator to type your secret numbers into form fields. That way, a key logger doesn't detect what you'd normally type into the field. Requires just a little bit of JavaScript to do so.

However, if Trojans would also track mouse positions and clicks in very small intervals, and likewise store the window dimensions, this method doesn't work any longer. You would need a human to recreate the login screen and figure out what buttons were typed though.

01-06-2004, 05:16 PM
you could just randomize the images so that none appears twice at the same place for each user I guess... That would seem a bit weird for the client I guess but that would do the trick would'nt it?

01-06-2004, 06:23 PM
Yes, could be.
But it's not done that way in the example I mentioned. I guess it's too confusing for the user to have the number buttons randomly sorted. But the <div> that contains these buttons could be positioned slightly different for each user, if the interface permits it by having enough whitespace to fill.

I don't know if such a measure really adds more security, since it seems much easier to get at authentication data through social engineering, i.e. tricking the user to hand out sensitive data.

01-06-2004, 10:47 PM
I see... very interesting subject though. Glad that I learned some excellent things in that thread :)

07-20-2005, 05:58 AM
I'm looking guidance as to the general architecture for a specific purpose. I would like to have members of my site/store to only be allowed access to download a music track if it has been purchased. Things I would think I would want to check for before sending the file are: Is user valid and logged in? Does some unique session or ID exist that identifies the file she seeks with a processed order? Has too much time / too many downloads passed so that they are no longer able to download?

Obviously, this is much more complicated than presenting a user with the full URL to a file once Verisign has OK'd the credit card. In this scenario, anyone who could get ahold of the link could grab the file or worse, if the link is like http://site.com/files/blah.mp3 they could just go up to http://site.com/files/ and have their pick of the catalog.

What typically is done to control something like this? I think it's done in OS Commerce in some sane way to prevent unauthorized access. I just don't know what logic it takes to move from validating the requirements to delivering a binary file like an MP3.