Identicons are visual representation of hash values. Usually they look something like these :
As a matter of fact, GitHub uses identicons as profile pictures by default based on the username of users. Since no two users have the same username, every user has a unique identicon. It is also used in many blog sites to uniquely identify each user even if the names are same.
Don Park came up with the idea of using identicons to prevent phishing in 2007 in this blog post.
This project implementation is inspired from that idea. I would like to tout this as an alternate way to sign in to websites to safeguard against phishing attempts. Everyday, we log in to multiple websites, whether it is for e-mail, news feeds, games or social media. There is always a risk that the webpage that loads could have been compromised by an attacker as part of a MiTM attack or a general phishing scheme and hence the danger of your accounts being compromised without you even knowing it.
A user loads up a website he/she wants to log into. The user then inputs his username/email first. This is sent to the server where it's validated for an existing record. If yes, then the server generates an identicon from the hashed password and sends it back to the users' browser. The user can see the identicon generated from the server. At the same time, the user's browser fetches the hashed password (read: password manager fetches the password it must have stored before) and generates the identicon. Both the identicons are placed side by side. If they are identical, then the opened site can be trusted. Now, the user can safely input his/her password.
The major dependencies used are :
- Flask - 1.1.2
- Flask-SQLAlchemy - 2.4.4
- passlib - 1.7.2
- pydenticon - 0.3.1
- sockets - 1.0.0
- SQLAlchemy - 1.3.19
For the complete list check this.
This implementation does change the user experience. Obviously, humans don't embrace change.
Firstly, the user needs to store passwords in the device. Password managers provide a solution to this issue. But, people rather use the crappy password managers built into the browsers. The idea of "all eggs in one basket" seems to frighten them.
If you have any suggestions or anything about how this isn't going to work at all, let me know. Open a PR, maybe.
As of now, this implementation just shows how the system may work, it doesn't fetch credentials from a password manager to create identicons at the client side. It has proven to be challenging. For testing purposes, I created another database which acts as a storage unit for credentials, imitating a password manager.