0

What books or tutorial (online/downloadable) shall i learn to be able to make secure page? I need to know different technique and algorithms

3
Contributors
13
Replies
14
Views
7 Years
Discussion Span
Last Post by phyrtech
0

Learning to write secure PHP code for a website is about a lot more than encryption. Encryption is only one part of creating a secure website. Enabling encryption on the site will vastly increase security as information will not be sent in plain text across the Internet.

The scope of "website security" is huge. There are hundreds of facets to consider all of which depend on the specific project you are working on. Here are a few links to get you started:

http://www.phpfreaks.com/tutorial/php-security

http://phpsec.org/

http://php.net/manual/en/security.php

You will also need to keep abreast of new PHP and web-related security developments.

I would highly highly recommend pursuing some kind of formal education regarding these topics. It is simple to write a PHP script. It is hugely difficult to ensure that it is secure and will remain secure for the foreseeable future.

Sincerely,
Nate

0

What books or tutorial (online/downloadable) shall i learn to be able to make secure page? I need to know different technique and algorithms

There aren't really that many techniques (and 0 algorithms to remember) to secure your site. MD5 your passwords, scrub your inputs AND outputs, use prepared queries (PDO). I'm all for being strong in CS but as far as PHP goes unless you're hell-bent on being able to give the user their password back on reset you're not going to be using cryptographic algorithms too much.

0

There aren't really that many techniques (and 0 algorithms to remember) to secure your site. MD5 your passwords, scrub your inputs AND outputs, use prepared queries (PDO)..

is MD5 secure? Every place i read of hashing, md5 is being bashed of being insecure but they don't really get to the point where they tutor you

I'm all for being strong in CS but as far as PHP goes unless you're hell-bent on being able to give the user their password back on reset you're not going to be using cryptographic algorithms too much.

Please, explain a little bit

0

is MD5 secure? Every place i read of hashing, md5 is being bashed of being insecure

Well if this is true then 99% of the PHP websites out there that do authentication are fucked. :P

Please, explain a little bit

The only use-case for encryption during securing a PHP site is if you want to encrypt passwords rather than hash them. If you encrypt them you can decrypt them and email them back to the user if they lose it. If you hash it you can't do that because it's one way, you'll just have to send a random password back to the user.

Edited by ShawnCplus: n/a

0

Learning to write secure PHP code for a website is about a lot more than encryption. Encryption is only one part of creating a secure website. Enabling encryption on the site will vastly increase security as information will not be sent in plain text across the Internet.

I need only to apply it to login/register form. I wan't it to be secure enough like Joomla/Drupal. No overkill like CIA web ;)

The scope of "website security" is huge. There are hundreds of facets to consider all of which depend on the specific project you are working on.

Sure, and I know I cannot cover all. I want that one enough to get my pages secure. I work on webpages+Database (MySQL)

Here are a few links to get you started:

http://www.phpfreaks.com/tutorial/php-security

http://phpsec.org/

http://php.net/manual/en/security.php

You will also need to keep abreast of new PHP and web-related security developments.

Thanks a lot for the links

I would highly highly recommend pursuing some kind of formal education regarding these topics. It is simple to write a PHP script. It is hugely difficult to ensure that it is secure and will remain secure for the foreseeable future.

Sincerely,
Nate

Thanks for recommendations. I will think about that :)

0

Well if this is true then 99% of the PHP websites out there that do authentication are ****ed.

What you are likely referring to is the fact that someone somewhere showed that an md5 hash collision can be found in less time than is theoretically possible. And some day processing power will be so abundant that one-way hashes of such a small bit-size will be easily cracked.

Here is an example of a possible security problem with one-way hashing algorithms (called collisions):

Say we have a hashing algorithm that outputs a 24-bit hash (3 bytes) called HashIt. If it outputs 24 bits but you can input as many bits as you want, then clearly more than one input must yield the exact same output:

if
HashIt(this is an input string) = 'abc'
AND
HashIt(this is a different input string) = 'abc'

then we have a collision. The more collisions that a hashing algorithm exhibits, the more easy (theoretically) it is to break the algorithm and therefore "hack" an account.

It is highly preferable to use SHA-2 instead of Md5 since it has a larger ciphertext size and therefore is theoretically stronger.

For password handshaking I highly suggest you look into the SHA-HMAC mechanism. You should also consider using some sort of "salt" when creating md5 hashes.

I need only to apply it to login/register form. I wan't it to be secure enough like Joomla/Drupal. No overkill like CIA web

I strongly encourage you to secure any transfer of usernames or passwords with SSL. This eliminates the need to hash passwords before transmitting them to the server. Additionally, it protects the username as well.

On a side-note (and a gripe of mine): I absolutely hate websites that will send your plain-text username and password to your e-mail account if you forget them. This is a HUGE security problem. Think of how many people use the same password for everything.

0

The only use-case for encryption during securing a PHP site is if you want to encrypt passwords rather than hash them.

I don't know what is better, but I plan to encrypt them than hashing them. But If hashing will have added advantage I can think of it

If you encrypt them you can decrypt them and email them back to the user if they lose it. If you hash it you can't do that because it's one way, you'll just have to send a random password back to the user.

I think I should send them random link to change their password than send them plain text password

0

I don't know what is better, but I plan to encrypt them than hashing them. But If hashing will have added advantage I can think of it


I think I should send them random link to change their password than send them plain text password

If you are going to hash a password, there is no need to first encrypt it. A hash is a one-way, irreversible process that makes it impossible (well, very very difficult) to recover the input data. If the hash is strong, the only way to find the input text is to try every single possible input text and compare the output to the output you already have:

HashFunction([unknown input text]) = 'abc'
In order to find [unknown input text], we must try every possible value that it could be and see if HashFunction([our test value]) = 'abc'

I agree that you should send a link which will allow them to change their password. Most sites also implement a security question such as:

What was the first car you ever owned?

or

Please enter your billing zip code:

etc.

0

so which is the best, hashing or encrypting? seeing that I don't need to recover the original password. All I need is security and ability for user to login (which can be done by comparing hashes)

0

so which is the best, hashing or encrypting? seeing that I don't need to recover the original password. All I need is security and ability for user to login (which can be done by comparing hashes)

Hashing is definitely more secure and the preferred method. Hashing makes it so that no one can get the password back. Most sites use password hashing to authenticate users.

If you encrypt using the same key for every password, a disgruntled employee or hacker can obtain the key and decrypt the passwords.

If you encrypt the passwords with a randomly generated key, then the ciphertext will likely be the same size as the original password (unless it is padded somehow) which will give some information about the original password to a hacker (albeit not much useful information).

0

So hashing is the best!
Cool then. What is considered to be the best hashing algorithm? What about salting in hashing, necessary to increase security or another overkill?

0

So hashing is the best!
Cool then. What is considered to be the best hashing algorithm? What about salting in hashing, necessary to increase security or another overkill?

In my opinion, the best available hashing algorithm would be SHA-2 (SHA-384 or SHA-512 which are equally as strong). You could look into Whirlpool, but I can offer no recommendations on it.

Honestly, a one-time-pad carried by armored truck staffed by ex-special forces with assault rifles from your office to your client so that they can decrypt a login page is an overkill.

Implementing point-to-point encryption (SSL) with a 256-bit cipher and hashing passwords with SHA-384 using randomly generated salt is not an overkill for any kind of personally identifiable information you will be handling. Of course your SSL will have to be downgradable to 128-bit since many older browsers do not support 256-bit...

In the end it comes down to how sensitive the data you are protecting is and how susceptible your server is. If it is feasible that a hacker (or even a vandal who has access to your server physically) could gain access, you should not store passwords in a reversible format (plain text or encrypted).

On the other hand, if you are protecting useless information or information that is publicly accessible anyway, SSL is not necessary. For example, this post I am making right now will be publicly accessible and therefore it is not necessary to transfer this text over SSL.

This question has already been answered. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.