miGlanz

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?

I believe bittorrent traffic is subject to heavy deduplication. But what about legality?

How is that not possible today?

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.

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)?

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;

- in this case we encode some data in the barcode (it could be some login URL, e.g. https://example.com/srp/yourservice.com/?nonce=some_random_n...);

- 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;

- we check the result on the actual login page as well (e.g. using AJAX): we may simply poll some other URL, like: https://example.com/srp/yourservice.com/result/?nonce=the_sa... (of cource results signing/etc. comes into play here);

- 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.

I hope this time it's clearer.

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.

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?

So the original question remains, is it possible with bcrypt?

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)

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.

http://www.gatcka.com

It's a simple discussion board, w/o registration, very (too?) clean.

I'll start with the latter question: it depends which link you give to your friends: simply click 'Link to this wall', and you will be presented with a list of permissions. For each set of permissions you get separate link. It simply depends which link you give to your friend (it's more of an social thing than technical, I think).

As for threads/replies: yes, this is obvious thing to do, but I wanted to check if it's really that useful and demanded before actually implementing this. The same (possibly to lesser extent) goes for voting.