Messages

Actually, my primary professions deals with eCommerce applications. Remember some of the first points of the post. It's plain bad practice to really store a lot of stuff in a session. For this example I was just storing a user id. You'd retain all the user information server-side and never store such things in a cookie, regardless of encryption.

The idea of using just the user id is simply to verify something like a logged in user. You'd only actually pull the data for that user when it's actually needed. As for credit card stuff, it's generally not good practice to ever store credit card information in full without some sort of higher security anyhow. There's actually a rather specific set of information for PCI compliance that your application must follow when using credit cards. Now, even if you do happen to store such things, you generally don't show it to the user anyhow (especially over a non-SSL connection).

MD5 has been cracked already actually. It's a small enough hash that you can break it with today's hardware due to databases being able to easily hold every possible value and reference it rather easily with a rather simplistic dictionary attack. Your encryption is only as strong as the method you're using. For instance, SHA1 will likely be broken before SHA256 is, which will be broken before SHA512, which will be broken before other even higher encryption methods. Unix shadow files are an extremely small and rather easy to break hash much like MD5 (hell it's smaller isn't it?), so they weren't a strong hash to begin with.

Honestly, this method here is no less secure than just brute forcing something like a PHP session id. If anything, when using a higher encryption method it'd be more secure, because even if they have the user id (so long as your application itself isn't broken) there's nothing they can do with it unless they manage to obtain your secret key for your application. Only at that point is your security really compromised.

As one of my instructors once put it, if you really want your data secure, take your system offline, lock it in a safe, and drop it to the deepest part of the ocean.

We're actually about to do this for our main ecommerce software. We're finding that even with the standard PHP session shit, the disk i/o is really starting to kill performance. If we eliminate the session stuff it should help a hell of a lot in load.

Not sure how many people here actually do programming, but this technique is applicable to all web languages. I'll be focusing on PHP in this particular example though.

When writing website systems, there's generally a few rules of thumb that you want to always follow. First, you want your users data to be secure and second, especially on high traffic sites, try to offload anything you safely can onto the users browser.

Now, some people who have used things like PHP sessions are probably using it wrong. First and foremost, with ANY session system, it's usually horrible practice to store a ton of information in the session. Generally, you want to store only id's and use that information on your backend to reference the data. Never, ever, ever store the data directly in the session. Simply put, when you start relying on doing such a thing it can end up giving you unintended consequences later down the road.

The easiest example I think I can give for this would be something like user profile information. Say after you log in a user, you decide that to keep things easy you'll just store all their profile information into their session. In things like PHP the session data is read/written to the disk (or database) each and every page load, sometimes multiple times per page load depending on how you write your system. Not only can this kill your sites performance, when you start getting more and more data it can also cause unexpected issues. For instance, one day you decide to change the session handling to store the information in a database rather than the file system, but you start getting errors because information is being truncated off and corrupting the session data itself.

The simplest way to avoid something like that is simply don't do it. It's bad practice anyhow.

Now, another nice trick, is storing the session information on the users browser in a cookie. This gives you a few advantages. Not only does it significantly simplify your session handling, it makes it so you no longer need to store/retrieve this information from a database or file system. This is best done when you are actually properly using sessions in the first place (rather than storing all the users information, store just the user id and use that to reference the users information later only when you actually need it). However, you can't just store something like a user id and hope that you won't have malicious users spoofing information.

But there is a way, and it's actually quite simple. By using something like a server-side secret value (usually something extremely long and extremely random), and hashing functions you can safely place such a thing into a cookie and make it impossible to "easily" crack (by that I mean, no encryption in the world is 100% totally unbreakable).

First of all, you'll need a non-changing secret key in your application. Something which you never, ever, distribute out to anyone (it'd break any security you add to do so). For this example, I'll be using a random SHA1 hash, but you'd likely use something a little stronger.

Secret: 2bffd564c0979f5d4bf68ab630c5234fb38b3493

Now, say you have a user log into your site. We'll say that this particular user's id is 54.

Now here's where the magic comes in, you need to generate a cookie value using your secret value, the users id, and some random seed value that you'll generate on the spot now. So lets generate our seed:

Seed: 9389552

So we now have a seed (randomly generated for each new cookie), a user id, and a secret key. Lets make a cookie (for this demonstration I'll be using SHA1 one-way encryption, you may substitute this with any other method you wish, such as SHA256).

The basic formula for this is:

UserId + '-' Seed + '-' + SHA1(UserId + Seed + Secret)

which for this case would end up being:

54-9389552-5fd41536bfb364e6fec7922297f041f13445eea8

This here is the value you would store in the users value within your cookie. But this is only the first half of it. You'll need to read and validate the cookie too. So here we go (I assume people know how to read/write cookies who have gotten to this point).

First, if the cookie is set, read in the value. In this case the value of our cookie was "54-9389552-5fd41536bfb364e6fec7922297f041f13445eea8".

Now, split the cookie up so you have the user id, seed, and generated sha1 value:
uid = 54
sed = 9389552
hsh = 5fd41536bfb364e6fec7922297f041f13445eea8

At this point you have all you need to make sure that this cookie is valid to allow access for user 54 to the user. Simply compare the hash with another hash generated using the same method above:

If 5fd41536bfb364e6fec7922297f041f13445eea8 EQUALS SHA1(uid+sed+Secret)

then your id is valid, otherwise they're spoofing and you can handle it however you want to.

What happens if something goes down?

Some of the more advanced spam bots are able to get past common captchas. This is why things like generating an image with simple addition and asking the person to enter the answer work better.

Other methods that confuse spam bots are things like a bunch of images, named different animals with the corresponding animal in the image except one image (which would still be named the name of an animal but wouldn't actually be an animal), then asking which one isn't an animal. This method requires image processing techniques which are kinda far beyond the scope of a bot making your forum less worth the time.

Just keep in mind, some spammers are actually human so no captcha will stop them. That's where a good amount of decent moderators come in.

I'm happy because I just bought a 2005 Ford Mustang convertible with less than 60k miles on it for under $13,000.

If it runs on Ubuntu, it'll likely run on a few other releases like Fedora as well.

You could in fact do this without something like PHP, but it'd be kind of a pain in the ass. That being, you'd need to use Javascript, AJAX, and XML parsing. Which honestly, you'd be better off going with the PHP.

Why not just code it to always use a default user if there isn't one set?

Keep in mind that things like Google (and other search engines) tend to catalog every single bit of your site that it's allowed to (restricted by /robots.txt). So the 404 activity access may very well be search engines attempting to update their records for the things you've removed. That or you managed to kill off some hot linked images.

For those who don't know about robots.txt, this is a good start:
http://www.robotstxt.org/

It's simply a text file, there's not really a whole lot to it. But it's useful if you don't want some things being indexed by search engines.

You did much more than most people would. To be honest, you probably did more than enough. Showing the person that someone she doesn't even know can care about her may have helped in a decision for care. Nobody can force someone to get medical treatment, if they refuse it there's nothing that you can do.

At this point just hope for the best, but don't dwell on it to the point to hold your own emotions down.

Actually, this is due to the way some of these browsers write to the disk cache. I notice this too on both my laptop and desktop from time to time (less on my desktop since it has a significantly faster disk though). It has something to do with waiting for all current disk cache write operations to complete before it writes or something like that. I don't recall the details... I also thought that was fixed.

You're terrible "people" huh? GG grammar.

Welcome Kylo!

That's exactly what I'm saying. Sure that method is fine when you're drawing a poster, but it's still bad practice to go straight to drawing how things will look. I've worked on quite a few large scale professional sites now. I can assure you that while that practice may work for something really small like a personnel site, it sure as heck fails in larger scale team-oriented setups.

You always start with a basic layout, get your content into place where it needs to be, and THEN make it more visually appealing. You need to figure out what exactly you're going to be working with. In my case, I'm one of the primary programmers on our web development team. We generally put the absolute basic stuff into place for the designer because we know what content the system will have initially, or at least what sorts of features it will have. We then leave it up to the artist to build a stylized design to replace the basic layout design (sometimes things move but generally not often).

Keep in mind that my views on this are influenced by working for a professional development company in a team. Not soloing everything.

I'd like to point out that the person in that article is off on some things. He outlines that there are 2 phases in the site development process. This simply is not true.

There are in actuality 3 or more. The first phase isn't the design phase at all. It's layout, which shouldn't be confused with design. Content layout is a very important and key aspect to your sites accessibility. Your layout is in essence a sort of framing for your design, but it has a lot more significance. Generally it's best to put together your site in the most basic means possible. If it's at all possible to apply content that you'd be using in the final design (news articles, banner stand-ins, site location, navigation, etc...) it's not a bad idea to put some of this into the basic layout. Layout is in fact a coding phase, but when I say "simple" design I mean simple. No pretty bordering, no pretty images, background, javascript driven slideshows, or anything like that.

Once you are through the layout phase and have a good idea how you want things to display on your site. THEN you enter the designing phase. This is the point where you take the layout that you came up with which works with your content, and make it look pretty. You can use many tools to do this as he stated. I know many people who do things all the way from freehanding designs to using stuff like photoshop. When coming up with your site design, there's one thing you should always keep in mind. You're making a website, not a poster. While a website can be a work of art, that's not as important as it being functional. If your site is a really pretty poster design, but difficult to use, you've failed.

After you have your design, you'll need to actually apply that to your layout. At this point you should have a really good idea both how you want your HTML to layout, as well as how you want it to look. This is where the really intricate HTML and CSS stuff comes in (as well as Javascript on occasion).

Then you start getting into even more in depth things which may or may not apply to you. Such as server side scripting to take your site design and apply it as a template to your content dynamically.

To recap... never, ever, ever, start by just drawing something out. That's horrible design practice. Always start with your *basic* html layout, then do your design artwork for that layout, finally apply your art to the layout. Doing this will help ensure that you're not biting off more than you can chew for the more intricate design work.