<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom"><title>Simon Willison's Weblog: scott-johnson</title><link href="http://simonwillison.net/" rel="alternate"/><link href="http://simonwillison.net/tags/scott-johnson.atom" rel="self"/><id>http://simonwillison.net/</id><updated>2003-02-08T23:53:25+00:00</updated><author><name>Simon Willison</name></author><entry><title>Hashing client-side data</title><link href="https://simonwillison.net/2003/Feb/8/hashingClientsideData/#atom-tag" rel="alternate"/><published>2003-02-08T23:53:25+00:00</published><updated>2003-02-08T23:53:25+00:00</updated><id>https://simonwillison.net/2003/Feb/8/hashingClientsideData/#atom-tag</id><summary type="html">
    &lt;p&gt;Via &lt;a href="http://radio.weblogs.com/0103807/2003/02/08.html#a1323" title="PHP and OWASP Security"&gt;Scott&lt;/a&gt;, a clever &lt;acronym title="PHP: Hypertext Preprocessor"&gt;PHP&lt;/acronym&gt; technique for ensuring data sent to the browser as a cookie or hidden form variable isn't tampered with by the user:&lt;/p&gt;

&lt;blockquote cite="http://www.sklar.com/page/article/owasp-top-ten"&gt;&lt;p&gt;
If you're expecting to receive data in a cookie or a hidden form field that you've previously sent to a client, make sure it hasn't been tampered with by sending a hash of the data and a secret word along with the data. Put the hash in a hidden form field (or in the cookie) along with the data. When you receive the data and the hash, re-hash the data and make sure the new hash matches the old one.
&lt;/p&gt;&lt;/blockquote&gt;

&lt;p&gt;A further explanation and example code can be found in &lt;a href="http://www.sklar.com/page/article/owasp-top-ten"&gt;PHP and the OWASP Top Ten Security Vulnerabilities&lt;/a&gt;, a handy article describing how &lt;acronym title="PHP: Hypertext Preprocessor"&gt;PHP&lt;/acronym&gt; coders can combat the top ten web application security problems highlighted by a recent report from &lt;a href="http://www.owasp.org/"&gt;OWASP&lt;/a&gt;. Incidentally, &lt;acronym title="The Open Web Application Security Project"&gt;OWASP&lt;/acronym&gt; still haven't fixed the cross site scripting vulnerability &lt;a href="http://www.owasp.org/%3Cscript%3Ealert(%22boo%22)%3C/script%3E"&gt;on their own site&lt;/a&gt;, discovered by &lt;a href="http://tom.me.uk/blog/"&gt;Tom Gilder&lt;/a&gt; several weeks ago.&lt;/p&gt;

&lt;p&gt;Incidentally, while the hashing method is clever and should be nice and secure I personally advocate not sending the user &lt;em&gt;any&lt;/em&gt; information unless absolutely necessary - use sessions and store sensitive data on the server instead. I suppose you could always use the hash to add an extra layer of security to the session identifier though.&lt;/p&gt;
    
        &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/hashing"&gt;hashing&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/owasp"&gt;owasp&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/php"&gt;php&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/scott-johnson"&gt;scott-johnson&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;&lt;/p&gt;
    

</summary><category term="hashing"/><category term="owasp"/><category term="php"/><category term="scott-johnson"/><category term="security"/></entry><entry><title>Remembering passwords</title><link href="https://simonwillison.net/2002/Dec/5/rememberingPasswords/#atom-tag" rel="alternate"/><published>2002-12-05T02:23:47+00:00</published><updated>2002-12-05T02:23:47+00:00</updated><id>https://simonwillison.net/2002/Dec/5/rememberingPasswords/#atom-tag</id><summary type="html">
    &lt;p&gt;Via &lt;a href="http://radio.weblogs.com/0103807/2002/12/04.html#a1019" title="One of the Most Useful Articles in a Long Time: How To Remember Your Passwords"&gt;Scott&lt;/a&gt;, an &lt;a href="http://howto.looselycoupled.com/blog/2002_10_27_dy.htm#85623755" title="How to remember all your passwords"&gt;article&lt;/a&gt; with some great tips on remembering your passwords. It includes the following vitally important tip:&lt;/p&gt;
&lt;blockquote cite="http://howto.looselycoupled.com/blog/2002_10_27_dy.htm#85623755"&gt;&lt;p&gt;
You may trust the provider you're signing up with, but are you confident no-one will hack into their database? If in doubt, err on the side of caution - be safe, not sorry.
&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;A few years back I nearly learnt this one the hard way. An online gaming forum I had signed up for was cracked, and the password file started making its way around the less scrupulous members of the UK gaming community. The first I heard of this was when someone used my username and password form that forum to log in to my account on a different forum and post some messages. The bad news was that I had administrator access on the different forum, which at that time had over 20,000 active members and nearly 2 million posts.&lt;/p&gt;

&lt;p&gt;Luckily the prankster in question didn't cause any damage and contacted me to warn me to change my password, but it gave me (and the other administrators of the forum) a pretty big scare.&lt;/p&gt;

&lt;p&gt;Ever since then, I have maintained a minimum of 3 passwords. I have a low security username/password for unimportant accounts, a medium level one for sites that I trust to a greater extent than the low security ones and a number of high security passwords used for e-commerce sites and important admin level accounts. I should probably start spreading myself even thinner.&lt;/p&gt;
    
        &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/passwords"&gt;passwords&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/scott-johnson"&gt;scott-johnson&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;&lt;/p&gt;
    

</summary><category term="passwords"/><category term="scott-johnson"/><category term="security"/></entry></feed>