But do we need one (I mean social graph)? I believe our code (ie. github) or advices (ie. SO) speaks more than social graph when it comes to programmers, doesn't it?
It could be 'serverside' rather than 'clientside'.
As in, sure you can connect the AIM and MSN chat networks, but you yourself have to run a server to connect the two.
Currently one also has to have migration functionality written by themselves. Instead, amazon could provide it, just like AIM could provide an MSN gateway themselves.
You're clearly ignoring the fact, that it's mostly US-only issue, and it doesn't have to be that way. We, non-US citizens, can't do much about it, and we'd like to get attention of US folks (who often are less affected), because they (you?) can.
I'll probably get downvoted for it, and I'd like to be mistaken here, but I'm getting the feeling that some of you get offended by critique, justified or not, of some of US politics.
I am not a US citizen, I don't see what TSA or US immigration officials' incompetence (which is certainly real) has to do with US politics - certainly not what it has to do with Hacker News.
Colin, one question: let's say I'm not paranoid about my backups' security. So I don't want to re-encrypt anything (even though it's only about 1GB). How does upgrade to 1.0.28 affect existing and new backups (and deduplication among those)?
Tarsnap 1.0.28 is completely compatible with earlier versions (except for key file format changes in 1.0.22). The only nontrivial change was to make new uploaded data get encrypted correctly.
Hi Zed, I had this idea recently which might somehow be related to yours (or complement it, to be more precise).
I was thinking about making various password managers (KeePassX, etc.) work better with web sites and about
storing your passwords on your mobile device and use this device to easily log into services (for example
when you're away from your PC). So the idea was basically this:
- show me a 2d barcode (QR-code, datamatrix, whatever) on your Sign-in page;
- I scan this code with my mobile phone application (or simply use desktop application that takes a screenshot);
- this application (password manager) makes a request to your service and authenticates me (using SRP);
- your Sign-in page uses AJAX in the background to check if I'm already authenticated;
- if the auth process was finished - I'm redirected to login-only area of your site;
So this 2d barcode would contain some kind of nonce that would uniquely identify current Sign-in
page (we obviously can't use cookies because we're using different channels).
This whole idea could also make sign-up process much more simple (you could, for example,
encode password requirements for your site, and my password manager would automatically
generate the password according to these requirements, and would sign me up and record
credentials in itself).
Just an idea. I'm not sure if it's viable at all (there might be some hard-to-overcome security issues),
it would be nice if you let me know what you think about it.
I'd have to look at it more, but I think doing the 2nd factor auth before a simple password auth will have problems. What you really want is they login like normal, but then they get a txt message or use an app on their phone to do the 2nd factor.
2 factor auth though is very much possible with this, actually with any service. I may try to hack that up as a demo this week. Maybe use twilio for it and have it call you. Fun!
I wasn't thinking about second factory actually (unfortunately I can't easily express my ideas in English, I haven't made it clear enough). The barcode would make a first (and only) factor. Of course username/password would stay there for backwards compatibility.
Once again, I'll try to express myself more clearly:
- we show a username/password input boxes and 2d barcode (QR/datamatrix);
- the user may simply enter his username/password and then everything works your way;
- he may also choose to use some kind of password manager that is compatible with this protocol;
- this password manager scans the code and performs full SRP authentication on the above URL; if it's successful we simply send some kind of notification to your service - or you poll our service for the result;
- if the result is OK we simply set session data in the cookie as usual and from now on the user is authenticated;
This has additional advantage of the actual crypto going on in the password manager and on the server. It also gives the possibility to perform the sign-up process semi-automatically as well (think of password generation - the user doesn't have to know it at all). And then think of public wifi or other networks you don't trust: you may perform the auth via GSM using your mobile. But the biggest improvement, in my opinion, is the usability aspect. You could have your password manager lying in the background and when you are shown a login page you could simply double-click an icon in your tray area and you are immediately logged into the app. Or you could use password manager on your mobile phone to take a shot with its camera.
What about performing the hashing again, on the existing hash (of course it would be simplest to encrypt from the beginning when user logs in again, but just for discussion's sake). Let's say we have a legacy db with hashes created with small work factor. We could simply perform the hashing on these previous hashes (increasing work factors as appropriate). We could simply annotate the fact that one have to perform the hashing two times.
Of course we're 'overthinking' it again, but is the above solution viable?
Imagine this Python code (I'm using SHA1 iterated multiple times, basically PBKDF2):
import hashlib
hashed = password
for i in range(50000):
hashed = hashlib.sha1(salt + hashed)
Provided we also store the number of iterations (along with the salt), and provided I didn't do anything stupid above, we could simply add more iterations after these 5 years and update hash and number of iterations field. Would it be a viable solution?
I don't know, but Oliver Hunt suggested just validating the password on the next login and upgrading it on the fly, which, to be honest, is what I'd probably do.
Nope, it doesn't change path. Path changes are after the hash. Although when you hover over the arrow pointing to the next page it shows different path, it's probably for browsers with JavaScript disabled. Clicking this link is also intercepted by JavaScript.
EDIT: sorry, it actually does change the path on Chrome. It doesn't on Firefox.