4 ms·

The key question, is how does the authenciation server know that you are who you say you are? I am not trying to make so,etching that's unbreakable, in the end

• unimpressive 14y ago
  Well, first of all; I would like to note that I am not a cryptographer, and that the following "model" might be based on a fallacious understanding of crypto. It's one of those things on my "list of stuff to investigate." The abstract might look like: Most users, when they sign up; supply a username and password to a website. Everyone hates remembering passwords, and this property compromises the security of passwords. (I'm sure you are well aware of why, and I won't go over that.) So one solution I thought of, would be if you had a program that (ideally) worked in the background, with minimal interaction from the majority of users, to sign up for a website. Usually this program takes the form of something like keeppass. [0] As far as I can tell, this is the best solution out there in terms of Security VS. Convenience. Even better, it can be added to browsers with a simple patch or extension. Of course, if were already taking away the users requirement to remember a password, this opens up new avenues for establishing ones identity. One such avenue might be a public key cryptographic system. A simple version may resemble these steps: 1. You sign up for a website with a public key instead of a password. 2. The website, at authentication time; generates a random string and asks your client to sign it with the private key. 3. Your client sends back the signed ciphertext. 4. The server verify's your signed text, and grants you access to the system. There are several advantages to this system over passwords: 1. Barring critical flaws being found in encryption algorithms, a public key system is almost uncrackable by means of brute force. Virtually eliminating brute force as an attack method. 2. It makes the concept of attackers gaining access to a "password database" a non-issue. You can generate a single public key and use it on a million sites, or generate a public key for each site; either way it doesn't matter if an attacker steals a database of public keys with yours in it. At least; not nearly as much as if they steal a database of passwords with yours in it. 3. This exchange can be handled entirely in the background, allowing for things like truly automatic log ins. 4. The exchange does not rely on 3rd parties to authenticate you. (Think OpenID) 5. Most of the work to make this system feasible has been done, all that is required now is an implementing client and implementing servers. Some disadvantages of this scheme include: 1. If somebody compromises the security of your computer, they can grab your private keyring. This can be partly mitigated with a master password encrypting the private keyring itself. 2. Phishing is still a viable method of gaining entry to your account, especially if you use a public key on multiple sites, because those sites can take the random string from the site they want your account on, and then present that to you as the authentication for their site, without you ever being alerted. The best way to mitigate this is to use one key pair for one site. An extra security feature might be to have sites log every time a request for a random string for you to authenticate is made, and then the client can compare that to the number of requests it has made. One way to mitigate phishing attacks may be for the website to provide it's own public key at sign up time that your client can use to verify its integrity. (But then, isn't this the point of SSL?) 3. If you use one key pair for one site, then the time it takes to generate a key must be taken into account. If it is prohibitively long, users won't want to do it. 4. The key database must be present on every device the user would like to authenticate on, as some platforms such as Apple's Iphone require proprietary development tools such as Xcode and MacOSX, the party implementing the client must have funds to support the development of multiple clients on multiple popular platforms. 5. It is virtually impossible to memorize a private key, meaning that users can not memorize their authentication details as a safeguard against the separation of them and their keyring. 6. A user getting their account back after losing their key without compromising the security of the system is...a troublesome problem. [0]: (https://en.wikipedia.org/wiki/Keepass https://en.wikipedia.org/wiki/Keepass) PS: Before implementing this, consult with a real security expert, who can probably point out egregious flaws if they exist.