Just doodling wih ideas like I used to do with rocks and dirt when I was a kid, I am wondering what the aural version of identicon (identitune?) might be like and how it would be generated from random bits? It'll help visually impaired folks to distinguish large numbers but not necessarily text.
Turning a sharp corner, I think identitune could run amok copyrighted melodies. But I like the idea of assigning people, places, and things melodies of their own…

Jason: "I am very tempted to do something similar for mobile phone numbers!" – Great idea. I get cross-eyed when I scroll through my contact lists on my PC as well as my cellphone.
 Dominic Cronin comments: "Perhaps it also makes sense to use this when managing a network with lots of different machines." – Bingo, Dominic! Using identicons instead of using the same PC icons in the list or graph of machines in the network will make it easier to distinguish them.
Using identicons to represent products (i.e. ISBN or SKU) will enhance readability of invoices, shipping list, etc.

I'll update this post as suggestions keep rolling in. 🙂

---

Some design tips:

Multiple Types of Identicons in a Page

If your use case uses more than one 'class' of identicons within a single page (i.e. wiki page using identicons for names as well as links) then you can help users distinguish different identicon classes by wrapping them with class-specific borders (i.e. circle for people and square for links).

I have come up with a couple of new, simple yet very effective, anti-phishing protection schemes using Identicon. One of them requires client-side support so I am interested in talking to browser vendors to build it into browsers ASAP.
It's main features are:
* dead simple user experience

* no certification infrastructure or black/whitelists used

* protection against DNS-based MITM attacks

* protection against keyloggers
Too good to be true? Well, I was surprised too when the idea hit me like a bullet. It's one of those obvious ideas that hides in the logical blindspots we all share. In a roundabout way, it's related to my idea of using DRM to protect one-time passwords but very different once it hatched.
Anyway, if you are a browser vendor, contact me.
Update:
Heck, I am just going to share the idea with the world because I want to see it implemented before yesterday.  

---

    <h4>Gemini </h4>
            The idea, which I am calling Gemini  for reasons explained below, is to: <em>Use the User&apos;s Password to Authenticate the Server.</em>
         A user&apos;s password is a shared secret which only the user and the server knows. So the server can use it to authenticate itself to the user, by sending a derivative of the password to the user. For example, if the server sent something like <strong>SHA1(password + host_ip + time)</strong> to the client where time is truncated to account for clock difference and the client did the same, two values must match if the server is authentic. <em>The crazy idea of sending the password to the user was the logical blindspot I mentioned. I walked into this idea when I started with the idea of broadcasting passwords. Yes, I am indeed crazy. LOL.</em>  
         The idea is called Gemini because, instead of comparing digested values, identicon images created from digested values are compared visually side-by-side by the user. If the identicons, one from the server and another rendered by the client, are placed either inside or near the password input box, users can easily compare the two before typing the password in. If the two identicons don&apos;t match, then either the server is a phishing site or there is a MITM (proxy will have the same effect).<br><br>Gemini identicons won&apos;t match if there is an intermediary, like a MITM or proxy, between the client and the server because host&apos;s IP address is used to build the identicon. DNS-tricks don&apos;t work because the MITM don&apos;t know the password.<br><br>The overriding assumption here is that the client is managing the passwords, each associated with a host name so the correct password can be selected and used to render the client version of the identicode. Since all popular browsers of today have this capability built-in, all they are missing is the Gemini functionality. For protection against keyloggers, I would add one-click keystroke-less password submission as well.<br><br>Gemini does change the user experience because, in order for the server to build its identicon, it needs the user&apos;s name. If Bank of America&apos;s SiteKey deployment is of any indication, this is not a significant issue.<br><br>Another gotcha is that browser&apos;s identicon has to be authenticated to the user. This can be done by rendering a randomly selected desktop-specific frame around the identicons being compared, like some of those exotic chinese seals have unique looking borders. Simple square or a circle drawn with unique line/gap pattern and color will look great I think.
   Although I was part of the team that built the technology behind SiteKey and feel that it is one of the best anti-phishing solutions out there, I frankly think Gemini is the superior solution. But if any of you see any holes or issues with Gemini, I would appreciate hearing about it. After all, I could be a butterfly hallucinating.
 
<hr>
<strong>Butterfly</strong>
 Speaking of hallucinating butterfly, the reverse of Gemini is interesting too although it appears to be only a slight variation of the usual hashed password method. The only difference is that client&apos;s IP is thrown in to stop the MITM. 
If it is the client that sends the user name and <strong>SHA1(password + client_ip + time)</strong> to the server then the server can check (using the same algorithm) to authenticate the user. This reduces the need for login UI to a single OK/Cancel box and both the phisite site and the MITM can&apos;t do much with the hashed password it captures because:
1. reversing hashed password into password is impractical.
2. hashed password can&apos;t be used because client IP address would differ.
3. replay becomes irrelevant. 
One weakness I can see is the client-based malware somehow getting at the passwords stored on the client, but that can be addressed if the OS uses proper access control.
                        Thinking more about this, this scheme can be reduced to using following three factors:
1. Something the user knows or has: password
2. Something the user uses to access: IP
3. Something no one has control over: time
Re phishing, note that there is no need to authenticate the server to the user in this Butterfly scheme. Although a phishing site can theoretically emulate a website&apos;s secured area to capture sensitive information at some later point, displaying information only the true site posseses can be used to implicitly authenticate the server. 
               <hr>
                    
Tags: tech, security, identicon

Speaking of client-side, I can now take on a new client. If your company* has interesting projects (it really doesn't matter in what area, what matters is creativity and dexterity) and have the budget to hire a heavy hitter, let's talk.
* EMC and divisions of EMC are not welcome without a letter of apology from their CEO.

Suggestion from Wes Felter and a good cup of coffee prompted me to write an implementation of Identicon using the canvas tag. If you are using a browser with canvas tag support (i.e. Firefox), take a look at the Identicon Canvas Test page. If not, the screenshot below will have to do because the example falls back to server-side identicon. I am going to hold off on deploying on my blog until I figure out how to get around a Safari canvas-related bug.

 <p align="center"><img src="//www.docuverse.com/blog/donpark/files/identicon_canvas_test%5B5%5D.gif" alt="" width="407" height="224"> </p>
 FYI, updated <a href="//www.docuverse.com/blog/donpark/files/identicon_0_3_src.zip">Identicon source package</a> (version 0.3) includes the canvas implementation code. You can take a look at the javascript <a href="//www.docuverse.com/blog/donpark/files/identicon_canvas.js">here</a>. As you can see from the example and javascript file, identicon code is stored in canvas title attribute. Kinda funky but *shrug* it works.

Feel free to use this at your own website. 

Third-party implementations and variations of Identicon are starting to appear. I'll add to this post as they appear.

• ScottS-M now has a WordPress plugin port with extra shapes.
• Charles Darke has implemented a variation called Visiglyph using PHP.
• Andi at Splitbrain has a Combinatoric Critters version called MonsterID
• ScottS-M wrote WP_MonsterID, a WordPress Plugin version of MonsterID.
• FriedCellCollective has a MonsterID web service.
• Jeff Atwood and Jon Galloway with help from Phil Haack has a .NET 2.0 port!
• Jon has details of the porting process using JCLA.
• Daniel has a C# version that returns bitmaps.
• Didier is implementing a python version.
• Kai Carver has a Perl version which he is using on visualizing sentences.
• Sean Kearney has a Community Server add-on version of Jeff/Jon's .NET code.

    If you have an implementation or a variation of identicon, comment to this post to get added to this list.<br><br>
    To encourage others, I&apos;ve just uploaded <a href="//www.docuverse.com/blog/donpark/files/identicon_0_2_java_src.zip">Identicon version 0.2 source code</a> which has following changes:
           1. Cleaned up and refactored to remove unnecessary crap and simplified flow for improved readability. 
           2. Documented. I am still not happy with the level of documentation but at least it&apos;s getting better. 
           3. Description of how identicon is rendered from a previous post is included in doc folder.
           4. Fixed a color-related bug. This means your identicon color will be slightly different.
           5. IdenticonCache interface added to allow caching identicons. IdenticonServlet will check the cache if the full class name is provided using &apos;cacheProvider&apos; init-parameter. 
           6. Runtime jar file (com.docuverse.identicon.jar) is included.
         Enjoy.
         PS: Until I fix the dang CSS bug caused by indented blocks, you&apos;ll see some odd layout problems.
          
          
        
Tags: tech, security, identity, identicon

To help people undersand why and what of identicon, I hoisted up one of my comment to previous posts.
I originally came up with this idea to be used as an easy means of visually distinguishing multiple units of information, anything that can be reduced to bits. It's not just IPs but also people, places, and things.
IMHO, too much of the web what we read are textual or numeric information which are not easy to distinguish at a glance when they are jumbled up together. So I think adding visual identifiers will make the user experience much more enjoyable.
I think identicons have many use cases. One use is embedding them in wiki pages to identify authors. Another is using them in CRM to identify customers. I can go on and on. It's not just about IP addresses but information that tends to move in 'herds'.
 

I’ve updated Daily with following identicon related changes:

• Your identicon is shown in the comment form so you won’t have to post a comment to see it.

• ETag support now works to give my server some relief.

Persistent identicon changes require some database changes so expect some delay on that.

My implementation of identicon is written in Java so you’ll have to port the code if you are not using java. If you are, it’s just a matter of hooking up the servlet, set inetSalt init-parameter, and you are ready to go.

Anyway, here is the preliminary (pre-cleanup/pre-documentation) version of Identicon source code. License is simply Go-Nuts-With-It. If and when later versions are released, it’s likely to adopt more formal license.

Documentation? You’ll have to make do with this single sentence version for now (sorry): IdenticonRenderer renders identicons, IdenticonUtil has code that derives identicon code from IP address.

Update:

Since non-java folks are starting to port the code before it can be properly documented, allow me to describe the rendering code to help them with their task.

How to draw an Identicon

A 9-block is a small quilt using only 3 types of patches, out of 16 available, in 9 positions. Using the identicon code, 3 patches are selected: one for center position, one for 4 sides, and one for 4 corners.

Positions and Rotations

For center position, only a symmetric patch is selected (patch 1, 5, 9, and 16). For corner and side positions, patch is rotated by 90 degree moving clock-wise starting from top-left position and top position respectively. This means 2 bits out of identicon code is used o select the center patch, 4 bits each for corner and side patches, 2 bits each for starting rotation of corner and side patches. In the source, each block array contains 4 rotated versions of each patch. You can do the same or generate the rotated versions on the fly.

Coloring and Inverting 

I am using white background with a patch color selected using 15 bits from the identicon code, expending 5 bits for each color component (R, G, B) placed at high-end of the component value (bits << 3). 1 bit per patch is used for inversion, meaning selected color will be used as background and white used as the patch shape color. Note that patch 16 is just an inverted version of patch 1.

32 Bits

Adding it up, you are using 32 bits ((2 + 4 + 4 + 2 + 2) + (15 + 3)) to render an identicon.

Poorman’s Anti-aliasing

While the shapes themselves can be rendered directly using anti-aliasing, I got better result from drawing a scaled up version then scaling down to requested size. Also it’s faster this way and works with graphics toolkits without anti-aliasing support.

Let me know if you have any questions. BTW, I am going to add more types of patches, symmetries, and quilts in the near future which will make wider variations of identicons. Wild!

---

Update 2:

Charles Darke has implemented a variation called Visiglyph using PHP.

I’ve just added preliminary 9-block IP identification feature to Daily, my blog server to enhance commenter identity beyond name and website. Basically, what I am doing is using a privacy protecting derivative of each commenter’s IP address to build a 9-block image and displaying it next the commenter’s name. To see this in action, you’ll have to drill into the post view to see the comments.

The derivative is currently first four bytes of SHA1(IP + salt). Since dynamic IPs change, you’ll see 9-blocks change over time for a particular user. But it doesn’t seem to change often enough to affect IP identification within typical comment activity clusters. I could reduce this problem by changing the derivative to SHA1(CIDR(IP) + salt) but CIDR blocks could get pretty big. I am looking into ways (i.e. identify router-level blocks) to solve this problem.

Anyway, you can see your 9-block by commenting to this or other posts. I’ll add a couple of test comments to start with.

Update:

Anything new needs a good name so one can refer to it easily. My first choice was identicon but I’ve decided to go with identiglyph or idglyph because identicon was used elsewhere. I am back to being undecided. Identicon is just too perfect. I hate being wishywashy.

Update 2:

Source has been released.

Update 3:

The number of comments to this post is getting rather unusually large which interferes with user experience. How about giving my other posts, like Identicon Explained, Application Ideas for Identicons, Identicon-based Anti-Phishing Protection, Canvas-based Identicon, or Third Party Identicons some of your identicon love? 🙂

I've been looking at authentication lately and wanted to share three authentication methods I came up with. I think they are new but then I haven't searched in depth to see if anyone else have come up with similar ideas so it's just a guess at this point.
Very Large Key-based SecurID
This idea uses my Very Large Key idea to simulate SecurID-like devices in software. SecurID-like devices, like the fob PayPal will be using, are just random number generators with device-specific seeds. The device generates a random number for each 30 second time slot during which the random number can be used to authenticate with servers that knows the device's seed. If the random numbers are pre-generated (about 168MB for 10 years worth) and saved to a CD or a dumb USB flash drive, the result is similar to SecurID (minus the temper-proof feature that is). Right mixture of auto-play and copy protection schemes can be applied to raise the level of protection beyond sheer size.
DRM-based SecurID
With continuing investment in DRM technologies, DRM support in both hardware and software media players are common. What if one-time passwords are delivered to users as DRM-protected movie or audio streams, displaying or reading out password to the user at the point of entry? One-time passwords are useless to keyloggers and DRM technology offers reasonable level of protections against screen recorders. I don't think password movie streams have to be user-specific if reasonably large number of group streams are available and users are randomly distributed across groups.
F2F Authentication NG
This idea updates the oldest form of authentication, face-to-face interaction, with latest video chat technologies like Skype. At the point of authentication, a video chat session between the user and a verification personnel is started. A verification personnel is a real person who authenticates you by sight, voice, and, if need arises, asks you a few questions before letting you through. F2F authentication is not cost effective enough for average users and situations but I think it will become the preferred authentication method for VIP customers to protect high-value transactions.
That's it for now. Contact me privately (click my face ;-p) if you would like to chat about these ideas.