Your email password is the most important password. It links to your bank and any other sensitive info using the forgot password feature.
After reading the recent Lifehacker article How I’d Hack Your Weak Passwords I wanted to share my thoughts. I disagree on some points.
Tips on making your password hellish to crack:
- Stay away from names and words altogether. Example: “Mike1”.
- Avoid using Leetspeak (substituting letters with similar-looking numbers or symbols). Example “M1k3”. I disagree with Lifehacker’s suggestion to use Leetspeak.
- If you type quickly, use a long password such as “MyFavoriteRocket” or even with spaces—”My Favorite Rocket”. Most password hacking tools stop at 14 characters.
- Use a phrase without vowels. “A Penny Saved” could be “APnnySvd”
- Add more variety by adding your favorite number in the middle: “APnny23Svd”
- Alter the variety by holding down shift when entering the number: “APnny@#Svd”
- Use a simple pattern and theme for all your passwords. Maybe favorite book/movie titles or favorite actors.
- Don’t use your email password for any other account. A hacker can use your email account to get passwords reset using a “Forgot Password” feature.
There is a surprising amount of confusion about XSS and SQL injection among the PHP programmers I’ve worked with. Here are some common ways to do it right and to do it wrong.
Escaping Input (protecting against SQL Injection):
- NO: add slashes or run mysql_real_escape_string() on everything in the REQUEST before using.
- YES: strip unexpected characters and validate data. If you need a phone number, don’t allow all types of symbols, for example.
- YES: use SQL binding before inserting database data. PDO offers some nice binding. All PHP frameworks offer systems that automatically bind data. At the least, use mysql_real_escape_string() or the correct one for your database engine.
Escaping Output (protecting against XSS):
- NO: run strip_tags() on the way in. strip_tags() is not meant for scrubbing input can let in malicious HTML. In fact, using string_tags() is probably never what you need.
- NO: run html_entities() before anything comes into the database. What if you need to write database data to a printed check? You don’t want to accidently print “O'Connor” on someone’s check.
- YES: use an HTML parser with whitelisting on any data coming in from a WYSIWYG (e.g. HTMLPurifier).
- YES: cast numbers to integers or floats.
- YES: use view helper functions to format dates, dollars and other data.
- YES: run html_entities() on all text, even if you “know” it is safe. The view is autonomous and should assume all input has not yet been escaped.
- YES: Get familiar with ha.ckers.org research and OWASP recommendations.
I’m surprised by how many developers aren’t familiar with encryption. Many say to me that encryption is md5 and sha1.
Applications often need one-way encryption and two-way encryption. There are also public/private key encryption schemes like pgp which are not as commonly used in web applications.
All Developers should be familiar with using md5 and sha1 and with using mcrypt. Most importantly, always store passwords encrypted—one- or two-way encryption works.
When using encryption to keep data secure, there are many considerations.
One-Way Encryption Suggestions
- Use a salt string to add more variety
- Store the salt string in a safe place where web surfers can’t see it
- Don’t send the salt string across the network (e.g. don’t store it in a database)
Two-Way Encryption Suggestions
- Use a strong algorithm such as AES (not Triple DES or Blowfish)
- Store the key in a safe place where web surfers can’t see it
- Don’t send the key across the network (e.g. don’t store it in a database)
- Don’t decrypt data then send it across the network (e.g. encrypt/decrypt in MySQL)
- Keep it simple by storing the iv padder with the encrypted string and keeping the encrypted string in base 64
- Pretend that the information you store is your own; would you be uncomfortable if a hacker saw it? Always encrypt information like social security numbers, credit card numbers other account numbers. Consider encrypting personal data such as name, phone and address.
I’ve had some colorful interviews lately. It brought to mind a lot of DON’Ts in Interviews and Resumes. I capitalize DON’T because everyone should know these basic rules.
- DON’T make vague statements such as “worked with various technologies” or “used full AJAX functionality”.
- DON’T write in paragraphs. Write short bullet points without flowery words.
- DON’T cram your resume onto one page. Technical resumes can be as long as three or four pages. When you use liberal line spacing and concise bullet points, your resume should have plenty of whitespace. You don’t want it to look like a set of long paragraphs.
- DON’T wear distracting clothing. I don’t care much what you wear to work, but in an interview, I want to focus on your skills and experience, not your shoes and jacket. Wear simple business casual.
- DON’T make ridiculous generalizations. Don’t tell me that hacking is dead or that bitwise operators are unnecessary.
- DON’T tell me about unrelated inventions. I don’t care if you are Thomas Edison; I need a coder. Reminds me of Sean Spencer on Psych telling everyone about his pillow comb invention that reduces bed head.
- DON’T pretend like you know something. I’d rather hear you say “I don’t know” or “I’m not sure” than listen to an incoherent rant that skirts around the issue.
- DON’T get flustered when you have no experience in a particular area. The ideal candidate doesn’t need to know or have experience with everything.
- DON’T worry about finding the “right” answer. I want to hear you share your technical knowledge and experience. I’m not testing to see if you hold the same opinions as I do.
Yesterday I was playing Flash games with my 5 year old on our Ubuntu desktop. As you may know, Flash support on Linux is dismal. Specifically I was using the Adobe plugin on Firefox 3.6 in Ubuntu 9.10 with a powerful NVIDIA GeForce 9600-series graphics card and a speedy Intel Core2 Duo. We played games on flonga.com.
Here are some of the problems that made games unplayable:
- Gets stuck in a loop on the splash screen
- Annoying flicker
- Buttons don’t work (e.g. clicking “Play” does nothing)
- CPU usage was intense and game was slow
The problems seemed to crop up somewhat related to UI complexity, but I get the feeling that many of the problems are due to poor programming and a poor Flash implementation for Linux.
If these problems exist on powerful desktop hardware on Linux, I can only imagine the challenges of implementing Flash on Android or OSX mobile devices which have processors of 1 GHz or less and run on the equivalent of two AA batteries.
Recently I formed the opinion that mobile devices would kill flash Flash as Steve Jobs is pushing for. But playing the games made me realize that Flash on mobile could make Flash stronger!
See, I stayed away from any game that was unplayable. With a high number of users making the same choices, Flash developers and Adobe will adapt or die. Flash developers will avoid unnecessary UI complexity and slow animations. Adobe will re-factor slow code. Flash on mobile could make Flash stronger!
We’ve already seen that Adobe is chomping at the bit to get Flash on mobile devices; they’ve added interfaces for reading mobile-device-specific hardware such as accelerometers and GPSs.
Keep an eye out, especially as Mobile Flash rolls out to Android devices in the next few months.