-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Security Concerns About My1Login.com ==================================== ## Introduction This document describes my observations about the My1Login service. My1Login isn't the only online password manager service and possibly it's not the worst, it is just the one I stumbled upon. The purpose of this document is to help My1Login and similar providers to design and implement better and more secure services. The statements in this document are based on the publicly available materials provided by My1Login and personal user experiences. Testing of the service didn't involve attempts to access restricted information belonging to the provider or other users of the system, the goal of the analysis was to uncover design problems. ## About My1Login According to their website[1] "my1login is a free, online password manager that gives you highly-secure access to your passwords from anywhere". The company was selected as one of the top 100 startups competing for the Spark of Genius awards[2]. The company promises "military grade security"[3] based on the fact that the passwords are stored only in encrypted form on the My1Login servers and the encryption keys are only known by the users they belong to. ## Overview To use My1Login one has to register an account on the website providing an e-mail address, a password and an encryption key. To differentiate between the password used to log into My1Login and the ones stored by the service I will refer to the former one as "service password" and the later ones as "external passwords". My1Login claims that the key is never stored on their servers. External passwords are stored in encrypted form using AES-256 encryption[4] and the key given by the user. Encryption and decryption of the external keys are performed in the users browser via JavaScript scripts. After logging in to the service a client-side script verifies the users key and "unlocks" the store of the external passwords (the exact procedure is not important now). As the user visits an external site, he can use a special bookmarklet, that executes JavaScript in the context of the external site. This bookmarklet modifies the structure of the external site by loading scripts from my1login.com and adding new UI elements and event handlers. Using the new UI elements the user can instruct the client-side scripts to fetch the encrypted external password and decrypt it using the previously given key or to encrypt newly given credentials and store them on the server. ## Keylogger and Screen-Grabber Defense vs. Usability It is a long known truth that the weakest link in the chain of security is the human user, making usability a key factor in any security system. To login to the My1Login service one has to provide three randomly chosen characters from his service password. The characters are provided through three drop-down menus which show a dot if a character was already chosen. This solution is meant to protect against keylogging and screen-grabbing. However, according to my personal experience the most casual way to fill in this form is to * write down the service password on a piece of paper, so I know the position of each character (one of the goals of My1Login is to prevent writing down passwords[3]) * use the keyboard to select from the drop-down lists, so a keylogger can grab my strokes (those drop-downs are long) Also, making the login process this complex results in limitations in service password complexity and storage: * The character set of the service passwords is limited so the drop-downs can be generated * The service passwords have to be stored in reversible form (not hashed) on the server side, otherwise the character-by-character comparison wouldn't be possible I must also note that developing such methods against malicious software is basically pointless because in case of a malware compromise the sensitive information can be extracted in ways a web application can not control (like network interception, DLL injection or API hooking). ## Client-Side Encryption The security page[4] of My1Login says: "Security is one of the most important aspects of my1login and there are a number of ways that we protect the integrity of the service. There are also a number of other methods we use to protect the service however for security reasons we obviously do not want to give them all away." Well in my book, cryptography doesn't work that way[5]. Especially JavaScript cryptography[6]. But let's assume that cryptographic primitives and constructs are properly implemented at My1Login. My1Login basically states[3][4] that client-side encryption is useful because I don't have to trust the service provider since every important cryptographic process runs with a key only I know on my own computer. The problem is that My1Login implements host-based security and acts as a single point of failure[7]: If some malicious party (e.g.: criminal hacker, government entity or the provider itself) is able to take control of the infrastructure behind my1login.com, then any users key can be compromised in several ways. An attacker can for example modify the scripts loaded by the users from my1login.com in such way that the scripts will leak the key of the user to the attacker. ## Anti-Phishing My1Login defines the following procedure in order to help users avoid phishing attacks[4]: "In order to protect you against [phishing] my1login ask you to enter a personal 'Welcome Message' when you register. Every time you log into my1login with your Username and Password, your personal 'Welcome Message' will be displayed on screen that will allow you to validate that it is genuinely our site that you are logging into. As an additional level of security, the 'Welcome Message' will be displayed before you enter you decryption KEY, so if you don't see the message, don't enter your KEY." My1Login also utilizes SSL/TLS (and this is great) in order to prove the sites authenticity and to encrypt network traffic. Since most phishing attacks exploit the fact that users don't care about SSL/TLS (if they did, any other anti-phishing measure would be superfluous) I assume that some users can be convinced to give in their login credentials to unauthentic websites. First of all, displaying a Welcome Message after the service password is given is worthless, since at this point the attacker already has the sensitive information. This is true even if the user provides three characters at a time: the attacker can reply with "Login failed" messages and ask for different characters until the whole service password is given. Since the login process is quite complicated a user can be easily convinced that he made some mistakes. Second, an attacker can simply forward and intercept all traffic (including the login screen and the Welcome Message) between the victim and the My1Login server rendering this indicator useless. This method also allows an attacker to access the users key. However, instead of displaying a message chosen by the user, in practice the system displays an image randomly associated with the account after login in order to convince the user that he has given out his credentials to the right party. This solution is equivalent with the one described above of course. ## Disclaimer The views expressed herein are my own and do not necessarily represent the views of my employer or anyone else. ## References [1] [2] [3] [4] [5] [6] [7] ## Contact Name: Buherator E-mail: buherator at gmail.com PGP: 1DD5 6AFB 0660 4106 7B70 4F71 B84C 47BD 86EA 1855 URL: http://buhera.blog.hu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQq4eYAAoJELhMR72G6hhV24cH/RlJMTbHsn5hEMsv7bvQehLg uMn6THHyD3nJa3BPwI+6nUPCr8L8WkQ8NiP0mS7/ACYvrBz2bXpX7ZypMIdfeRWl 4FbcaLQE687JXpZl67YjT2oJEEnxOqJksmmg1NkAWPUCmATH1WR3/aA6xFBKIjc3 6kq0csjz+qqLH8lvvBmdABvg892dF0xJGMZpw0RuqHt/dbWiwXBRJh8+DJfOdBI/ lXydkRH8c9GZqCLkyKNvNIwanlGlBa+NQB2qWwPgiSyrQoehTq7pazYTQ1Aiit6U My6yh15xe+mW5Ry9y11Vhco46Yrwr+EvDaSNDynLxgtNCfQ1MCJPxg/y9SBWESM= =cp8B -----END PGP SIGNATURE-----