Topic: New approach to user authorization, 100% anonymous, secure and easy? (Read 627 times)
well, that's how it looks for now https://www.cryptonator.com/auth/login
May 16, 2014, 01:29:18 PM
I appreciate your efforts towards easy, secure and anonymous authentications. It is frustrating to remember so many passwords, and I never like using the same password because I never know if the server is actually hashing them!
I think the future of authentication will be ECDSA signing tags like the sigsafe NFC tag. The server would generate a random nonce, relay the nonce to the client, and then the client's browser would request an ECDSA signature from the user. With HTML5 and the Web NFC API (which is not yet ready), the browser would have access to the NFC reader. The user would tap his signing tag, the tag would sign the nonce, and the browser would then relay the signature back to the server. The user is now authenticated (perhaps using the bitID protocol).
The beauty of this technique is that the user can use the same signing tag (and same private key) for multiple services, as the services can only verify signatures (they can't forge them).
It looks like the mozilla has a prototype browser that can exchange NDEF messages with a NFC reader and HTML5. If you guys can get this working, we could use the sigsafe tag that I'm working on to produce the signatures.
I think the future of authentication will be ECDSA signing tags like the sigsafe NFC tag. The server would generate a random nonce, relay the nonce to the client, and then the client's browser would request an ECDSA signature from the user. With HTML5 and the Web NFC API (which is not yet ready), the browser would have access to the NFC reader. The user would tap his signing tag, the tag would sign the nonce, and the browser would then relay the signature back to the server. The user is now authenticated (perhaps using the bitID protocol).
The beauty of this technique is that the user can use the same signing tag (and same private key) for multiple services, as the services can only verify signatures (they can't forge them).
It looks like the mozilla has a prototype browser that can exchange NDEF messages with a NFC reader and HTML5. If you guys can get this working, we could use the sigsafe tag that I'm working on to produce the signatures.
will check it and get back to you asap. thanks!
May 16, 2014, 01:26:42 PM
How is encrypting the secret key going to work, if the key to decrypt needs to be on the server in case the user logs in? You're not adding anything here, since a knowledgeable administrator or attacker is going to know how to decrypt the data, obtain the key, and produce a TOTP token.
With passwords, at least the administrator only has a hash, and can't log in with information he's privy to. TOTP should only be used as a second factor.
Your model assumes that the owner of the site is also trustworthy, meaning it definitely isn't secure.
With passwords, at least the administrator only has a hash, and can't log in with information he's privy to. TOTP should only be used as a second factor.
Your model assumes that the owner of the site is also trustworthy, meaning it definitely isn't secure.
Secret key protects some information, and has no value itself. If like you say administrator or owner is corrupt, why does he need keys, tokens and all that stuff? He could just get the whole database?
May 16, 2014, 01:05:31 PM
I appreciate your efforts towards easy, secure and anonymous authentications. It is frustrating to remember so many passwords, and I never like using the same password because I never know if the server is actually hashing them!
I think the future of authentication will be ECDSA signing tags like the sigsafe NFC tag. The server would generate a random nonce, relay the nonce to the client, and then the client's browser would request an ECDSA signature from the user. With HTML5 and the Web NFC API (which is not yet ready), the browser would have access to the NFC reader. The user would tap his signing tag, the tag would sign the nonce, and the browser would then relay the signature back to the server. The user is now authenticated (perhaps using the bitID protocol).
The beauty of this technique is that the user can use the same signing tag (and same private key) for multiple services, as the services can only verify signatures (they can't forge them).
It looks like the mozilla has a prototype browser that can exchange NDEF messages with a NFC reader and HTML5. If you guys can get this working, we could use the sigsafe tag that I'm working on to produce the signatures.
I think the future of authentication will be ECDSA signing tags like the sigsafe NFC tag. The server would generate a random nonce, relay the nonce to the client, and then the client's browser would request an ECDSA signature from the user. With HTML5 and the Web NFC API (which is not yet ready), the browser would have access to the NFC reader. The user would tap his signing tag, the tag would sign the nonce, and the browser would then relay the signature back to the server. The user is now authenticated (perhaps using the bitID protocol).
The beauty of this technique is that the user can use the same signing tag (and same private key) for multiple services, as the services can only verify signatures (they can't forge them).
It looks like the mozilla has a prototype browser that can exchange NDEF messages with a NFC reader and HTML5. If you guys can get this working, we could use the sigsafe tag that I'm working on to produce the signatures.
May 16, 2014, 12:41:47 PM
How is encrypting the secret key going to work, if the key to decrypt needs to be on the server in case the user logs in? You're not adding anything here, since a knowledgeable administrator or attacker is going to know how to decrypt the data, obtain the key, and produce a TOTP token.
With passwords, at least the administrator only has a hash, and can't log in with information he's privy to. TOTP should only be used as a second factor.
Your model assumes that the owner of the site is also trustworthy, meaning it definitely isn't secure.
With passwords, at least the administrator only has a hash, and can't log in with information he's privy to. TOTP should only be used as a second factor.
Your model assumes that the owner of the site is also trustworthy, meaning it definitely isn't secure.
May 16, 2014, 05:49:32 AM
Hey guys!
We are now working on some sort of an authorization solution, which we wish to be anonymous, secure and convenient at the same time. We gave up classic email/password scheme and came up with login + 2FA one-time-passwords (via Google Authenticator, Authy, Duo Mobile, HDE OTP etc).
What we currently got is
1. User is offered to create a login (limited to A-Z, 0-9), which is (along with some random params) then hashed into some secret key.
2. Using login and secret key via another crypto-algorithm we generate QR code which user scans with his 2FA app on a mobile device and after successful verification we let him in.
3. To log in later, he enters a login and a 2FA one-time-password generated on a mobile device.
4. Since there is no email provided and the secret key is the only way to restore access to the account, user is offered to backup the secret key via email, sms, print it etc.
If user wants to use 2FA on other device, he could easily link it in account.
If user thinks his account might be compromised (mobile device stolen or lost), he can easily re-generate his secret key in account and re-link the mobile device
To prevent brute-force, login is blocked for 60 seconds after three unsuccessful attempts regardless of the IP.
There's also a possibility allowing logging in with the secret key only, in case 2FA is inaccessible.
Secret key is stored encrypted. Website uses SSL.
PROS
100% anonymous and very secure
No email/password required
2FA one-time-password is changed every 30 sec
CONS
2FA authorization is required every time to log in
If mobile device is hacked or stolen, account could be compromised, as the secret key stored locally on device (unless new secret generated in the account)
If secret is lost, account not accessible
What do you think?
We are now working on some sort of an authorization solution, which we wish to be anonymous, secure and convenient at the same time. We gave up classic email/password scheme and came up with login + 2FA one-time-passwords (via Google Authenticator, Authy, Duo Mobile, HDE OTP etc).
What we currently got is
1. User is offered to create a login (limited to A-Z, 0-9), which is (along with some random params) then hashed into some secret key.
2. Using login and secret key via another crypto-algorithm we generate QR code which user scans with his 2FA app on a mobile device and after successful verification we let him in.
3. To log in later, he enters a login and a 2FA one-time-password generated on a mobile device.
4. Since there is no email provided and the secret key is the only way to restore access to the account, user is offered to backup the secret key via email, sms, print it etc.
If user wants to use 2FA on other device, he could easily link it in account.
If user thinks his account might be compromised (mobile device stolen or lost), he can easily re-generate his secret key in account and re-link the mobile device
To prevent brute-force, login is blocked for 60 seconds after three unsuccessful attempts regardless of the IP.
There's also a possibility allowing logging in with the secret key only, in case 2FA is inaccessible.
Secret key is stored encrypted. Website uses SSL.
PROS
100% anonymous and very secure
No email/password required
2FA one-time-password is changed every 30 sec
CONS
2FA authorization is required every time to log in
If mobile device is hacked or stolen, account could be compromised, as the secret key stored locally on device (unless new secret generated in the account)
If secret is lost, account not accessible
What do you think?
Jump to: