Webpage Security and DBMS

[ContraHacker]

Hi, 

 

I want to start a project where I create a secure website for people where Its hard to crack the passwords and access the user's data. I want to know what languages I need to learn in order to make, say a secure login system. 

 

I know HTML CSS JavaScript and some basic PHP. And certainly an if/else statement to store passwords is NOT going to work. I have heard the word 'encryption' and 'keys' pop up, when dealing with secure login systems. So If anyone can clarify where to start, I'll be greatly helped.

 

Also, what are the latest databases running on these days? MySql? PHP?  

[Mornincupofhate]

PHP is a programming language, MySQL is a structured query language, so yes, the latest databases do run on MySQL.

 

Basically, if you want to keep your customer's data secure, the first step would be to encrypt everything inside the databases. I can't explain to you how encryption works because I have no clue either.

 

One popular vulnerability in webpages are code injections. Let's say a webpage has a search bar. When a user types something in and presses enter, the webpage might display "Results found for "Ham Sandwiches:" " < or whatever you typed into the search bar. One way you'd hack this is to "inject" your own code, any hacker will attempt to inject malicious javascript first. Example: In the search bar, someone can type in "<script> echo("This webpage is very vulnerable"); </script>" This would make a javascript popup box come up with that text. How is this malicious you ask? Basically when they do that, it will form a URL with something like http://www.yourwebsitehere.com/search?=<script>echo("This webpage is very vulnerable");</script>   Well, they can also inject code which will send the viewer's cookies to the hacker's webserver. The hacker can then put the cookies into his browser and he will now own their login session.

 

Another popular vulnerability are sql injections, also known as sqli vulnerabilities. These are the ones that can cripple companies, as they basically trick the server into believing that the hacker has more permissions than he actually does. I'm not going to go in depth because I've never learned mysql, but the code injection would be something like this (also used in search bars) --SELECT all from USERNAMES PASSWORDS     and basically they'd be able to drop the entire mysql into the webpage and download it or whatever they want to do.

[Niemand]

1 hour ago, Mornincupofhate said:

Another popular vulnerability are sql injections, also known as sqli vulnerabilities. These are the ones that can cripple companies, as they basically trick the server into believing that the hacker has more permissions than he actually does. I'm not going to go in depth because I've never learned mysql, but the code injection would be something like this (also used in search bars) --SELECT all from USERNAMES PASSWORDS     and basically they'd be able to drop the entire mysql into the webpage and download it or whatever they want to do.

 

@ContraHacker

Khan Academy has some nice introductory videos on encryption, I'd check those out to get familiar with the concept.

[burnttoastnice]

Also, ensure any login-related pages are served over HTTPS

[colonel_mortis]

If you're creating a website where users can have accounts, you are almost certainly going to want to use a database. Among other things, in that database, you will have table for users, which will contain, at a minimum, their username/email and a representation of their password. Never, under any circumstances, store the plaintext password anywhere. For more details on different password storage mechanisms and their weaknesses, you can watch Tom Scott's video about how not to store passwords, but in short, you should store a salted hash of the password. What that means is that you add some random data to the password (or using some algorithms the random data is actually used separately from the password), then pass it through a one-way "encryption" algorithm, which will always give the same output given the same input, but can't be reversed without just brute forcing different combinations. To do that in PHP, the most secure, and strongly recommended, method is to use the built in password_hash and password_verify methods (which will handle secure salts and hash algorithms for you):

// When creating an account
$thingToStoreInPasswordColumnOfDatabase = password_hash($passwordEnteredByUser, PASSWORD_DEFAULT);

// When they come to log in
$isCorrect = password_verify($passwordEnteredByUser, $thingFromPasswordColumnOfDatabase);

PLEASE don't try to hash/encrypt/process the passwords yourself, because getting it wrong is very bad.

 

When you are using the database, the naive thing to do is to write a query like

$query = "SELECT * FROM users WHERE username='" . $usernameEnteredByUser . "'";

However, this is vulnerable to an SQL injection attack, where the user enters something like "admin'; DROP TABLE users;--", which would result in the following query being run:

SELECT * FROM users WHERE username='admin'; DROP TABLE users;--'

resulting in two queries being run, the second of which deletes your users table.

To protect against this, you need to use prepared queries, which are where the query that can be executed is sent separately to the data. I'm not going to give all the code needed for prepared queries in this post, because it would make it significantly longer, but you should be using the PHP library PDO for it.

When using prepared queries, you should never have any variables in the prepared query (no "SELECT * FROM users WHERE " . $anything) - any variable, even if you think it is trusted, should be used as a prepared parameter, to avoid risk of inadvertently adding an SQL injection vulnerability.

[Fourthdwarf]

I'm going to make a suggestion which might be counterintuitive:

 

Don't bother with passwords.

 

If you watch the video that @colonel_mortis suggested, it briefly touches on this.

 

Use something like the OAuth or OpenID system, where another site handles identity/login.

 

This actually reduces password reuse (good for everyone) and reduces the risk of you making a catastrophic mistake.

 

Also, it helps ensure that you have a good set of tools for storing identity.

 

I'd suggest openID, as it doesn't restrict users to certain websites, they can roll their own if they wish. While you could use OAuth, there is no guarantee of compatibility, so users will be restricted to whichever sites you choose to implement it for.

 

(Final thoughts: xkcd.com/1353 - if you don't store it, it can't be hacked)

[vorticalbox]

54 minutes ago, Fourthdwarf said:

I'm going to make a suggestion which might be counterintuitive:

 

Don't bother with passwords.

 

If you watch the video that @colonel_mortis suggested, it briefly touches on this.

 

Use something like the OAuth or OpenID system, where another site handles identity/login.

 

This actually reduces password reuse (good for everyone) and reduces the risk of you making a catastrophic mistake.

 

Also, it helps ensure that you have a good set of tools for storing identity.

 

I'd suggest openID, as it doesn't restrict users to certain websites, they can roll their own if they wish. While you could use OAuth, there is no guarantee of compatibility, so users will be restricted to whichever sites you choose to implement it for.

 

(Final thoughts: xkcd.com/1353 - if you don't store it, it can't be hacked)

yeah im not handing over handling of logins to another system. What if it is hacked or taken offline? Then no one can use my site.

 

also if I don't store it someone else has to store it and when they verify the login send some sort of key to let them in. Something is always stored somewhere so use it can be hacked.

 

 

[Fourthdwarf]

6 minutes ago, vorticalbox said:

yeah im not handing over handling of logins to another system. What if it is hacked or taken offline? Then no one can use my site.

 

also if I don't store it someone else has to store it and when they verify the login send some sort of key to let them in. Something is always stored somewhere so use it can be hacked.

 

 

 

The openID system is near impossible to take offline completely, considering that Google & Microsoft are authentication providers for the system.

 

However I do appreciate the concern that a key (which is an OAuth key) has to be sent. This can be hacked. In fact, in any system this is a concern, and in general, rolling your own solution weakens security. Once again, I will point out that OAuth is used extensively by Google, Twitter and other tech giants.

 

Of course, the username and password is good for a large portion of the Internet, I was just providing an alternative solution which is at least theoretically safer.

[vorticalbox]

1 minute ago, Fourthdwarf said:

 

The openID system is near impossible to take offline completely, considering that Google, yahoo, Microsoft and even MySpace are authentication providers for the system.

 

However I do appreciate the concern that a key (which is an OAuth key) has to be sent. This can be hacked. In fact, in any system this is a concern, and in general, rolling your own solution weakens security.

 

Of course, the username and password is good for a large portion of the Internet, I was just providing an alternative solution which is at least theoretically safer.

I don't see how using a database with prepared statements and hashed password is any less secure.

Spoiler

fishing for information.

 

[Fourthdwarf]

 

23 minutes ago, vorticalbox said:

I don't see how using a database with prepared statements and hashed password is any less secure.

  Hide contents

fishing for information.

 

OAuth keys aren't susceptible to dictionary attacks or password reuse, whereas passwords are.

 

After that, it's all about the authentication process, rather than storing the information.

 

- You let the user decide who they trust to authenticate them. For all they know you might be harvesting passwords. (Not that I'm saying you are)

 

- You let someone else handle the authentication infrastructure. 2 factor authentication isn't often provided on smaller websites, because it's a pain to set up. Also, who can handle logins more securely: you or google?

 

- You need less time setting up accounts. No need to get an email address, password (confirm password). Not strictly security related, but it's a bonus.

[vorticalbox]

8 hours ago, Fourthdwarf said:

 

OAuth keys aren't susceptible to dictionary attacks or password reuse, whereas passwords are.

 

After that, it's all about the authentication process, rather than storing the information.

 

- You let the user decide who they trust to authenticate them. For all they know you might be harvesting passwords. (Not that I'm saying you are)

 

- You let someone else handle the authentication infrastructure. 2 factor authentication isn't often provided on smaller websites, because it's a pain to set up. Also, who can handle logins more securely: you or google?

 

- You need less time setting up accounts. No need to get an email address, password (confirm password). Not strictly security related, but it's a bonus.

it my not suffer from password reuse but doesn't it use the same password to with on all the sites you choose? How is that any different? One password use across many sites.

[Cruorzy]

My personal opinion is to the comments above to start low, try to make your own script first then you 'should' look at systems like that.

 

Let me create some sort of summary for creating a safe environment, this is to my knowledge and im sure the nice people will add the things i forget or not even aware of.

Only started a few months ago so im sure it will happen.

 

Getting Started : Before you get started start really really simple, and work on your own level to the thing you want to achieve. Trust me you dont want to set something online yet because it might be alot of editing when you notice somethings are missing.

Start with just making a simple Database structure for users and saving data and retrieving data of it, then try to update data etc. Do this with Prepared statements i would suggest using PDO, then you should use hashing/encryption for your passwords with the build in function password_hash() mentioned by @colonel_mortis 

18 hours ago, colonel_mortis said:

To do that in PHP, the most secure, and strongly recommended, method is to use the built in password_hash and password_verify methods (which will handle secure salts and hash algorithms for you)

Once you done that try to get a simple login page where you can enter a username and password and if it all checks out you get redirected to a page where is for example says "Hello, [Username]".

The way i did that was login in and if all goes good set the username in a session_cookie (always start the session before you assign session_cookies and dont store more then you need or any sensitive data just for safety)

 

Done that? nice but you arent even close

Now let me link some points which mostly link to a Tom Scott/Computerphile vid because they are awesome, watch the video and dont leave it by that. Go futher, google ALOT about it so you know more than enough to create this project. This is a thing you should spend ALOT of time in if needed too. Get familiar with this and make it as safe as possible, if are not sure or you not getting it try to open an thread with the problem your having most of these guys will help you gladly.

 

• SQL Injections
  • Tom Scott has a great video about this with a really simple explanation about it. at least watch this one and go further from that.
  • Mike Pound his video might go a bit fast but i'll just put it here.
  • First level of preventing this is prepared statements
• Password Hashing
• • This should be no problem since there is a lot of documentation for this never store it in plain text something like MD5 [Fun Video]
  • Tom Scott simplify hashing here majorly but might be still fun to watch
• Cross Site Scripting
  • Guess what Tom Scott has a nice video about this
  • Fun demostration about XSS is a video by Mike Pound
  • First step of preventing this would be htmlentities() function
• Cross Site Request Forgery
  • This red shirt guy has a great video about this.
  • First step of preventing this would be a CSRF Tokens

Always use HTTPS connections when working with sensitive data! I think this would be a standard thing these days and i even heard you could get fines for not doing it?

 

Then I'm not sure if different accounts on a SQL Database with different rights for the query's is still a thing?

 

Hopefully this will get you a bit further.

 

[Fourthdwarf]

3 hours ago, vorticalbox said:

it my not suffer from password reuse but doesn't it use the same password to with on all the sites you choose? How is that any different? One password use across many sites.

It's not one password across multiple sites: it's one login.

 

Basically, in this scenario, you are a relying party (rp). The user chooses an identity provider (ip), which is the only site they login to.

 

Ideally, they will choose an ip to login to that is more secure than you could provide.

 

The ip then sends you a certificate with all the necessary information to verify the identity of the end user.

 

The user only ever logs into the ip, but you get a certificate of identity that allows you to associate data with that person. The certificate is specific to your website.

 

Because the user only logs into the ip, there is only one password.

 

This means that if a site that uses openID gets hacked and the certificates are released, users can't login to other sites, even those associated with the same openID, because each certificate is unique to the ip/rp/end user combination.