That's true only for the initial password creation. During verification you could send down two salts, the real salt and a session salt. You double-hash the password on the client with both salts, and the server hashes on the server with the session salt. The hash that gets sent over the wire cannot be used for replay attacks.
I don't think it adds much security though. If you don't trust the channel to properly protect the transmitted password, it's not possible to build a trusted relationship with the server. You have to assume ssl works.
The server sends a challenge to the client. The client computes response = f(challenge, password), and sends the response. Then the server compares the response with its own computation of f(challenge, password). Since f is some type of hash function, we can assume that the client knew the actual password, as it would have been too hard computationally to come up with the correct response without it.
In such a scheme, the keychain can do the computation and the password never leaves the keychain. We can even go as far as to have the keychain be separate hardware (eg USB dongle), so the password never even has to exist on the client's computer at all.
I was simply trying to clarify the challenge-response mechanism for the parent poster, not suggesting you use keychain dongles everywhere.
Regardless, the idea that the plaintext password doesn't have to leave the device (whether the device is a dongle, your phone, or the keychain application) is a valuable consequence of the challenge-response mechanism, and I wish support for it were more widespread.
The reason for why it isn't widespread is because you also have to spread it across all your devices. Which is neither secure nor usable enough for the mainstream today.
Unless that is solved it isn't a solution worth considering.
Not worth considering as a 'fits all' solution, yes, but it still is worth considering for specialized cases; in general, those cases where the added inconenience is worth the added security. For example, some banks use effectively this for logging in to your online account. And that can be made to work with any device with a display and a keyboard:
- computer shows challenge#
- user types challenge# on bank supplied device
- bank supplied device shows response
- user types response on computer
I am curious about GPL compatibility in this situation. According to [1], software developed by US federal government cannot be licensed under the GPL since it is automatically in the public domain. However, the github repo readme makes the following claim:
"The project utilizes code licensed under the terms of the GNU General Public License and therefore is licensed under GPL v2 or later."
While I applaud this effort and wish to see more like it in the future, is there a possible issue with licensing here?
The way USA.gov puts it, government works are "not subject to copyright" or restrictions thereof, which I think explains the situation better.
I am having a hard time finding a model for (or even discussion about) what happens when government works have been derived from copyrighted material. Anyone know of another example?
But I'm assuming that since there is no copyright to the additions, from a copyright point of view it's essentially equivalent to the software from which it's derived.
Seems like it matches the situation of wanting to release your additions to a GPL codebase into the public domain. Doing that is perfectly fine[1]. It feels like a hole in the GPL for some reason though.
So obviously I don't work for the white house, but I suspect that since this code depends on bits of gpl'd code to function, they made the entire project licensed similarly.
Also, it is not as simple as you think, government code isn't always pd. If written by a contractor, the contractor/contracting organization can decide to not release code/work to the public.
Finally, if this code was written by Macon's team, and not by contractors, then you could maybe make an argument that the parts of the code that came from original gpl parts would be gpl'd, but not the code written by the wh team that doesn't depend on the gpl'd parts, as the code isn't distributed to end users the way the gpl mandates sharing.
Anyhow, I'm trying to simplify a lot here, but thought I'd chime in.
They can't, but only part of the code is public domain. If you want to use the whole pile of it, you do so under the GPL - if you pick out the changes made by the govt, then you can apply those elsewhere.
Insofar as the non-GPL part is specific to the GPL code, yes. If you reimplement the GPL code under a different license, you could reuse the public domain bits. I expect in most cases, it wouldn't be terribly worthwhile.
