I want to start testing them out with some of my projects and i promise to report back with the success or failure of this experiment complete with detailed reports.
key (sw or hw) - something you have and then lose,or malware finds the spare copy under the mat, or turns out to be flawed as reported by academic cryptographers or as designed by NSA
OAuth and federated login - one password to rule them all and then make malware devs happy when they phish you
browser "DNA", keystroke analysis, behavioral analysis, pictures of kittens - something you collect amd then malware "in the browser" clones and drops on botnet
2 factors - 2 somethings that keep IT admins and vendors employed and then users log in to Facebook and circumvent corporate systems using more user friendly services
smartphone - something that you have and then gets malware or lost or stolen or hacked via bluetooth
everything the end user could possibly do conveniently is simply projecting an illusion of security
anything that is inconvenient will drive away users (there's a reason Amazon has 1-click)
i suggest Facebook or G+ and adding a big lock png next to your FB login button....end users will feel very safe, i assure you
if you get traction - then hire/partner with very skilled developers who know how to write (or better reuse) high quality, secure code; add a very skilled network and systems security minded ops person to your team for best results
if no traction - well, then...ummm....
The user experience of passwords to secure financial information is too poor for us to use it and that's why we're exploring and testing other options with side projects
A bit long winded but he does make his point
I am not trying to make so,etching that's unbreakable, in the end, nothing is. I just want something that will take more than a few minutes for a talented hacker to crack.
Can you please explain bait more about how these crypto keys might work?
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.  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.
PS: Before implementing this, consult with a real security expert, who can probably point out egregious flaws if they exist.
Expiring qr codes is an awesome idea. I'll definitely look into that thanks