h a l f b a k e r yIf you can read this you are not following too closely.
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,
|
|
|
Sometimes a website will have their records subpoenaed. All the account details are then revealed. Sometimes a website is hacked. Lots of stuff is revealed. One way to reduce the effect of both of these situations is to segment a user's account into different pieces, each of which is independent
from the others and protected by a different hash of the same password. Using separate accounts for different features is also possible but too much effort on the part of a user. So long as these associations are not logged (e.g. if the subpoena requires them to be), the different parts of a user's account will not be associated with one another until that user is logged in. If more paranoid, one can even go a step further by requiring password re-entry for some of these features, thus eliminating associations from happening even after the user is logged in. Of course, the user's account name would be hashed with the password for all such logins (during the registration step, the username could be checked against a list of usernames to prevet collisions).
Take note that this functionality does NOT require users to be able to post anonymously, so long as the piece of their account which is associated with their login-related details is not associated with their unhashed username or with their account details.
The main downsides of this that I can think of is that password recovery/reset is not possible under this system and the system is more complicated to implement.
Clarification of how it works: Keeping clumps of data separated from one another while still allowing the owner full access is the sole purpose. The trick is that since every account uses a different hash of the user's password/username, there is no way to associate them together. This is akin to the use of salting to hide if a users'the passwords are the same but in this case the salt is to hide that your own password is the same for all portions of your account.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
Is this to protect privacy (dissociating
accounts and users) or encrypt vulnerable
user data? The really short hash would
make breaking the encryption on the
individual parcels very easy. |
|
| |
[aguydude] - if that IS your real name, in what context would this be even remotely desirable? |
|
| |
An account is just a structure that allows some level of persistence, other than that, it's meaningless. |
|
| |
If you don't want to link personal information to an account, then don't - simple! |
|
| |
In countries where secrecy in financial affairs is protected by legislation, accounts (in this case, bank accounts) are identified only by number - the banks do keep records of their customer's private details, but in systems that are kept strictly separate - making it extremely difficult for someone to find out the details of any financial transaction if they only know a person's name. |
|
| |
Authorities requesting details of any financial transactions can be provided with these, without necessarily giving away any details of the people or organisations behind them (until a further specific request/order is made) |
|
| |
If you're posting on a website that you fear may be subpoena'd, I'd avoid providing them with any personal information. |
|
| |
I think this is a good direction to go into, although I don't understand all the details. |
|
| |
"Personal information" is not a clear-cut either/or thing; aggregating data makes seemingly innocuous choices more powerful. |
|
| |
For example, if you're purchasing through the same vendor, your overall purchase history paints a much clearer picture of who you are than any individual purchase. If each purchase were impossible to connect to a central account, that would make it much more difficult to profile people. |
|
| |
Are you running a meth lab, or do you just have a bad cold? Are you building a bomb, or did you just repair your plumbing?
Do you have a weird sense of humor, or have you joined a cult? |
|
| |
I think a lot of people would enjoy anonimity and purchasing power. This requires the elimination of a TTP. If the 'bakery were pay per view, I would like to participate, but <strikethrough> may </strikethrough> won't want others to know. |
|
| |
WcW: The purpose of this system is purely to protect privacy, not data. |
|
| |
It would be interesting if the password itself were the instructions for 'sticking together' the components of your personal data. It would then be even more secure (but screw up password resets) if only a hash of the password but not the password itself were held by the site. |
|
| |
Data having their own security attributes at a nuclear level is part of what (real) info-security is all about... so it'll probably never fly in the real world. |
|
| |
Yes it's complicated to (re)implement a system. |
|
| |
Also important (and rarely if ever done) is provide data owner (which is the originator not the host) with feedback, ie: "your data <data> was accessed by <accessor> on <date/time> for <reason>" |
|
| |
//the banks do keep records of their customer's private details, but in systems that are kept strictly separate //
Yes, on a high density writable CD located in the HDD of a laptop that has been left on the 5:15 to Edenbridge from Waterloo. |
|
| |