h a l f b a k e r yA riddle wrapped in a mystery inside a rich, flaky crust
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
My basic Idea was for a random password generating utility based on private local key, URL, User Id and an Issue number. Not too different from several out there already. However...
It does not store any passwords just a list of URLs, User Ids and issue numbers. The passwords are generated on
the fly.
The basic version needs to hold the local private key too.
The service version ...
When you apply for the service by phone, a private key is randomly generated by the secure service provider and delivered to your machine over a secure connection.
My idea was for a backup service which allowed you to backup this list on the secure server. If your machine(s) were ever compromised, you can make one call to get all your accounts locked by the service provider, in a first instance. As you would with your credit cards.
If the idea caught on and websites accepted the idea for the secure site to automatically change the passwords. Then when you got a replacement machine one phone call to the secure site could do all the work of reopening all the websites for you.
The problem I can see is some one making bogus phone calls to provide a very complete denial of service.
This is why I am putting this forward as a half baked
idea.
Windows 2000 Kerberos Authentication
http://www.microsof...curity/kerberos.asp
Now you have. [jutta, Dec 10 2004]
[link]
|
| |
How would you stop the service version's private key, even though it will be sent by secure means, being cracked once it is in use by your local password utility? |
|
| |
The passwords would be ranomly generated using a random hashing algorithm. So each password may be generated by a different algorithm but to know which you would need to know the private key and the other inputs. So the likely hood of cracking it is reduced. it would also be possible of course for the secure provider to provide a totally new private key when ever it thought that the private key was compromised. |
|
| |
Sorry about the serious tone. I will have to sacrifice a couple of unblemished doves for taking this too seriously. |
|
| |
''We believe in one pastry, the Pie Almighty, maker of delicious desserts, of all that is tasty and unfrosted. We believe in one dessert, with graham cracker crust, the only wonderous dessert, eternally begotten of the Pie, baker from baker, oven from oven, true dessert from true dessert. Begotten, not baked, of one being with the Pie. Through him all pie crusts were graham. For our hunger and for our salvation he came down from heaven: by the power of the holy oven he became incarnate from the virgin tart, and was made a scone. For our sake he was burnt under Pontius Pielate; he suffered crisp crusts and was disposed of. On the third day his yeast rose again in accordance with the Scriptures. He ascended into The Great Pie in the Sky and is seated at the right hand of the Pie." |
|
| |
Deuteronomy, you mention similar ideas out there, can you provide links/info? |
|
| |
Since you're already working with a trusted third party, wouldn't it be easier to just use Kerberos? |
|
| |
Not everyone uses Unix and I have not heard of Kerboros for Windows
Apart from which this product was aimed at joe public who has never heard of Kerberos |
|
| |