Jacques1

Destramic, we all agree that good passwords are very important. The question is how you get there. Sure, a password policy is an obvious and simple approach, which is why it's so popular. But popular doesn't mean good. Do you really believe you can force a user to choose a good password? Do you think a user who at first doesn't give a shit about security suddenly changes their mind and comes up with some really good password? I don't think so. They'll use something like “AAbb11!!” which is just enough to make your validator happy but obviously not secure. At the same time, you get in the way of people who do care about security but simply use a different password scheme (like myself). Long story short, this is nonsense. It may sound good in theory, but it simply doesn't pass the reality check. If you actually care about password security, help your users with practical advice. Give them a link to a good password manager like KeePass, point them to the famous “correct horse battery staple” comic to explain the concept of passphrases. This is something which actually works in reality.

Actually, you shouldn't expect AUTO_INCREMENT to yield a perfect sequence at all. There are all kinds of situations when a gap can occur. For example, if an INSERT query is aborted due to a constraint violation or a transaction rollback, then the reserved numbers will be skipped and never made available to you. You cannot even rely on the order of the numbers. You may get a low number after a high number due to a deferred query. The only promise which AUTO_INCREMENT makes is that you get a unique number. The exact value depends on the underlying technical details and is more or less undefined.

And why do you need a single regex? This massively reduces readibility and robustness (as you can see), so it shouldn't be done at all. Are you struggling with some crappy validator? This kind of password policy is also extremely naive, annoying and counter-productive. Yes, we'd all love to have people come up with and memorize hundreds of super-long, cryptic passwords. But in reality, this isn't gonna happen: The users who don't care about password security will hardly change their mind if you annoy them with error messages. They'll simply add some symbols to their weak password to make your validator happy, which isn't very helpful. The users who do care about security often use a password manager or passphrases. That's when your policy actually gets in their way. For example, I always use 32 hexadecimal digits to represent 128 randomly generated bits. This is a perfect password, yet you won't let me use it. I'd have to manually choose a different one only to get past the stupid validation. That's obviously a problem. So what's the whole point? I think the whole approach is just nonsense. There are much smarter ways to promote strong passwords: Tell your users about password managers like KeePass. This is really the only realistic solution for managing dozens of different user accounts. Maybe add a password meter as an indicator for the user. This motivates them to choose a strong password instead of punishing them for what you think is a bad password. Since you cannot reliably estimate the strength of the password, it's also important that the check can be bypassed.

MySQL does not magically reset the AUTO_INCREMENT counter when you delete rows. Once a number is taken, it won't be used again. This is the easiest and most robust solution. If you absolutely must have this feature, you need to implement it yourself. But be aware that this is much harder than it may sound, because you have to deal with concurrent requests. For example, two rows may be inserted at (almost) the same time, in which case you must make sure that they don't take the same “next ID”. My advice is, just stick to whatever number you get. An UNSIGNED INT can hold numbers up to 4 trillion, so there's not exactly a shortage of IDs. And if your application cannot handle gaps between the IDs, then that's the problem which needs to be fixed.

No, I mean that any site can trigger arbitrary requests to any other site within the same domain. This is a huge problem. If a user visits a site, then this site can see any content and take any action on behalf of the user. The site essentially becomes the user and gets all their rights. For example, they're suddenly allowed to use the admin area of an entirely unrelated site. Relying on HTMLPurifier alone to remove all bad code is not a good idea. It's a great tool to increase security, but it's not the ultimate solution. You may also need to enable custom JavaScript code in the future (who wants a purely static website?). The solution is to put the user sites and admin areas behind separate domains so that they cannot access each other. For example: joe.user-sites.yoursite.com joe.site-admin.yoursite.com This still isn't perfect, because subdomains can set cookies for parent domains. For example, joe.users.yoursite.com could create a “global” cookie for .users.yoursite.com which is also valid for other user sites. But compared to the zero-security approach where everything is on one domain, this is a big step forward. I don't know what you mean by that. The attack scenario is that the malicious site delivers JavaScript code which is executed by the victim. The victim would then unknowingly make requests, and there's no way for you to detect that (the referrer would theoretically give away the origin of the request, but it may not be present at all).

You must have a separate domain and session for the admin pages. If you don't, then any vulnerability on the main site is likely to compromise the admin account as well, because there's no barrier between the two. For example, a malicious JavaScript snippet on john.yoursite.com can read and change arbitrary data on john.yoursite.com/admin. Actually, if you were to use paths instead of subdomains for the user sites, then anybody could access any admin area simply by getting the other user to visit their site. For example, yoursite.com/alice could access yoursite.com/bob/administrator via JavaScript, because they're both within the same origin. So you do need a separate admin subdomain to protect the admin account in case the main site gets compromised. Letting users “create” their own subdomains as suggested by kicken is also very problematic, because then there's no clear distinction between your content and the content of your users. For example, what if somebody registers a domain like payment.yoursite.com or admin.yoursite.com? This may even be abused for phishing-like attacks. If you do want to take this risk, do everything to avoid confusion between user-provided content and “official” content: Use special prefixes like “user_” for the subdomains or even sub-subdomains: joe.users.yoursite.com

Neither of this is a good idea. When things get weird and hacky, that usually means the approach itself is flawed. If you want to separate the scripts so strictly that they don't even share the session, then they should in fact be on separate domains or at least directories (with no common prefix). This is a clear and robust solution and lets you avoid any confusing hacks. Also note that PHP itself doesn't enforce the separation of sessions. All the parameters (name, domain, path etc.) only refer to the session cookies. The client is free to change them and use the session anywhere. To get actual separation, you have to store the information server-side (in the session itself, the database or whatever).

I wouldn't be surprised if you've been attacked in all kinds of ways. You have no security whatsoever. That small code snippet alone already contains two SQL injection vulnerabilities, a completely broken hash algorithm, a completely broken session logic and finally disclosure of database internals through error messages. No, it's not a good idea to just restore the tables whenever some script kiddie has dropped them. The next attacker may actually know what he's doing and take over your entire server. So you need to learn how to write proper PHP code and then fix the vulnerabilities.

If I understand the OP correctly, the two applications are in fact behind the same domain. In that case, you just have to put the authentication logic from one application into the authentication logic of the other application. For example, while you create the session for the one service, you'd also create a second session for the other service. Doing everything twice may be cumbersome, but it's the easiest and most secure solution. If you merge the two systems, there's a huge risk of introducing bugs and breaking the security. How complicated this project will be depends on the software, of course.

And what prevents me from using that information-sharing system to fetch a one-time URL for an arbitrary user and take over their account? publisacman, I strongly recommend you refrain from the idea, especially when you're completely new to PHP and MySQL. Many developers can't even implement a single log-in system. The chances of getting two systems with a complex single-sign on protocol right are close to zero. What will probably happen is that you break the authentication mechanism of both sites and end up with no security at all. In fact, if your websites are so closely coupled that you feel the need to sync the user accounts, you should think about having one website with a single authentication system and different subdomains.

For some reason you've hard-coded the limit parameter in the action URL. Remove it. But what's much worse is that your small code snippet already contains tons of security vulnerabilities, spaghetti code and bad practices. You need to start thinking about proper code, especially when you write web applications. Values need to be escaped before you can put them into your HTML markup. Never heard of cross-site scripting attacks? Stuffing all code and markup into one big PHPHTMLCSSJavaScript blob also isn't a good idea. This will bite you once your project becomes more complex. JavaScript code belongs into external JavaScript files, CSS rules belong into external CSS files, and HTML markup belongs into external templates. Keep things clean.

No, there's no other way. That's how the relational model works. Either accept it, or don't use SQL. There are many alternative database models which you may like better (search for “NoSQL”).

This is worse than the first attempt, mannygo. There are no “lists” in a relational table. A single field contains a single value. If you want a many-to-many relation between two tables, you need a third table which connects the rows -- just like you did in your attendance table: group_members - group_id (references groups table) - member_id (references members table)

Um, what? The table is a complete mess. You've stuffed numbers, units of measurement, lists of values, text and whatnot all into the same column. It's like an Excel spreadsheet from hell. Are you even aware that MySQL has different data types besides TEXT? So before you do anything, learn the basics of relational databases. Wikipedia has a couple of easy-to-read articles with a lot of examples. What's important to understand is that MySQL is not Excel. When that's done, the easiest solution for your current problem is to load the saved values and turn them into an associative array with this format: $selected_weekdays = array( 'Th' => true, 'Sa' => true, ) The values are irrelevant, what's important is that you can check the presence or absence of a particular weekday simply by checking if the key exists: if (isset($selected_weekdays['Th'])) echo 'selected'; // for the "Th" checkbox The problem is that you've degraded MySQL to a dumb text store, breaking almost all of its features: You cannot properly query the data. Even trivial tasks require weird string function hacks, because you cannot access the values directly. You cannot make sure that the data actually makes sense. Those text strings can contain anything, so there's a huge risk of ending up with tons of garbage data.

Then why does each member only have one group in your table layout? Either way, once you have an extra table which assigns members to groups, then there's no longer a circular reference, and the problem goes away. By the way, in your current layout, a person may be the leader of a group but not one of its members. Is that a problem?

“Doesn't work”? Can you be a bit more specific? What is the problem? What's the expected result, and what's the actual result? We don't know anything about your project or the data you're working with, so if you want us to help you, then we need concrete info. Have you echoed the resulting query and tried it in phpmyadmin?

What are you even trying to do? You hash a session value and compare the result with a hash stored in the same session. What does that tell you? And what's this strange "salt" string?

The whole approach doesn't make a lot of sense. The hostname obviously cannot contain an e-mail address, so why would you waste time checking "http://".$_SERVER['HTTP_HOST']? I'm also fairly sure that you don't have e-mail addresses within the path or the URL fragment, so again, why check them? What is the concrete goal? Check the presence of a specific URL parameter? Then why not simple check isset($_GET['the_name_of_your_parameter'])?

What's the problem? You've already written down the exact WHERE clause. Besides that, you definitely need to learn how to write secure queries with prepared statements or manual escaping. No, casting with intval() is not a valid approach. It's actually harmful.

Whatever strange reason you may have for fumbling with self-referencing records, don't do it. It's weird, and it comes with a lot of problems. For example, you won't be able to delete the row (unless you temporarily remove the foreign key and then add it again). Just use NULL like everybody else. In this case, NULL means that there is no parent. I also have no idea why you quote the number 1. Numbers are not strings. Yes, MySQL is sloppy and lets you do it, but it's still poor practice.

Foreign keys can only reference unique fields, so the PRIMARY KEY must come before the FOREIGN KEY. Otherwise MySQL thinks that id is a non-unique field. Declaring parent_id as NOT NULL also makes no sense, because then you won't be able to insert any rows at all. What's the parent of the very first row? It can't have one.

Simply don't use this class. It's poor and hasn't been updated for 5(!) years. A lot of the features are naive and will introduce bugs and usability issues rather than actually increase security. For example, it's complete nonsense to bind the session to one IP address. It's perfectly legitimate for a user to have multiple IP addresses and change them regularly, and at the same time a single IP address may be shared by hundreds or even thousands of users. If your application cannot deal with that, you have a problem. What you should do is learn about the various session-related threats and then write your own code.

That's a rather vague question. It obviously depends on the target sites. Some websites are script-friendly and maybe even have an API, others make it very hard to log-in and fetch data automatically. I hope the script is supposed to run on your own PC? Because storing all your passwords on some server certainly isn't a good idea.

Well, if you number the elements as they come in, then of course you'll end up with arbitrary x values within one group, and you won't get the same value again. Instead, number the elements per group. For example: $intermediate[$key][] = array('x' => count($intermediate[$key][]), 'y' => $y); The first element of a group will have the number 0, the second is 1 etc. If you want to start with 1, simply add 1 to the result of count().

First of all, you need to start thinking about security. You can't just drop client-controlled values like $_SERVER['PHP_SELF'] into your HTML markup, because this allows anybody to inject JavaScript code and attack your users. Every value you want to insert into an HTML context must be escaped with htmlspecialchars(). Regarding your original question, use explicit indexes to assign the checkboxes to the text fields. For example: <input type="text" name="hashtag[0][content]"> <input type="checkbox" name="hashtag[0][update]"> Of course you'd use a loop and a counter to number the fields.