会话ID为md5（time（））

I have the code:

if ($usernamelogin == $dbusername && $passwordlogin == $dbpassword)
{
    $hash = md5(time());
    mysqli_query($connection, "UPDATE users SET sessionid='$hash' WHERE username='$usernamelogin' AND password='$passwordlogin'");
    $_SESSION['id'] = $hash;
    $_SESSION['un'] = $usernamelogin;
}
else 
{
    echo ('Wrong username or password.');
}

I'm then using $sessionid, the SQL sessionid, and the usernames to verify if a user is real. This means that, assuming I have protection against an SQL injection, there are relatively few security risks, right?

I came here to ask, because this seems like an overly simple solution to a complex problem. All of the documents and websites I've been to have implemented much more complex, confusing, and sometimes insecure methods of verifying if a user is logged in.

Is this secure?

You shouldn't use md5(time()) to generate a session id, this is not secure. The time is liner and can be guessable, for example some websites show when the user has loged-in, you could use this information and brute-force to hijack his session id.

Second thing, you can also brute-frose on random time and there is a great chance you will get some random user session id. Also, there is a good chance that two users will have the same second thing is two users will have the same session id if they login at the same time.

Have a look at this great talk (DEFCON 18: How I Met Your Girlfriend 1/3), I watch it a long time a go, I can't remember the details, but I remember the speaker made series point about session weaknesses. Also, see OWASP wiki, it has great resources on web security and sessions security.

Please don't take this the wrong way but if you don't understand SSL, you shouldn't be handling money.

SSL Is used to encrypt communication between the browser and the server. Without it, anyone on the networks between the browser and server can see every request/response sent in clear text - passwords, account ids, credit card numbers(?), etc.

This is the difference between http:// addresses and https:// addresses. It requires both server and code changes

The server needs a certificate from a trusted authority to enable SSL (and some config changes) but that's not enough. You also need to make sure your code does things like only issues secure cookies - that is, cookies that can't be sent over http, should check SSL is enabled on incoming requests in case of server misconfiguration, etc, etc. It's a massive topic and I can't tell you enough in one answer to make you secure.

As an absolute minimum, your code should be secure against all the OWASP Top 10 vulnerabilities. This is the absolute bread and butter stuff for making any site secure.

You also need to read up on SSL/TLS and encryption in general. This will give you an overview of how handshakes/messages are passed back and forth.