Tim Starling wrote:
You don't need to store the original passwords in a recoverable form in order to rehash them. You can just apply extra hashing to the old hash. This is how the A->B transition worked, and it's how the B->C transition should work too, unless someone knows of some kind of cryptographic problem with it. It's a convenient method because it saves the cost of underground vaults, with no loss in security.
In that case you could always discard the private portion of the key-pair to produce a strictly "one-way" function. And at least with this scheme you always do have the option of moving to 'C' regardless of whether it can accept the end-products of B as inputs. Plus I would wager that asymmetric ciphers will stand up to attacks far longer than most hashing functions.
On 20/08/10 04:18, Jonathan Leybovich wrote:
Plus I would wager that asymmetric ciphers will stand up to attacks far longer than most hashing functions.
In a past life, I was a PhD student working on a broad military-funded project which aimed to break all known asymmetric cryptography schemes using large, expensive machines known as quantum computers. There will come a point, maybe even this century, when large-block symmetric ciphers like the WHIRLPOOL compression function will be the only sort of security we will have left, unless you don't mind the government being able to read all your messages.
Asymmetric ciphers are the only kind of widely-used cipher that have a known vulnerability which allows cryptanalysis exponentially faster than brute force, i.e. in polynomial time and space with respect to the key length. So I think your faith is misplaced.
-- Tim Starling
On Thu, Aug 19, 2010 at 5:20 PM, Tim Starling tstarling@wikimedia.org wrote:
In a past life, I was a PhD student working on a broad military-funded project which aimed to break all known asymmetric cryptography schemes using large, expensive machines known as quantum computers. There will come a point, maybe even this century, when large-block symmetric ciphers like the WHIRLPOOL compression function will be the only sort of security we will have left, unless you don't mind the government being able to read all your messages.
Asymmetric ciphers are the only kind of widely-used cipher that have a known vulnerability which allows cryptanalysis exponentially faster than brute force, i.e. in polynomial time and space with respect to the key length. So I think your faith is misplaced.
You must have missed the recent news. At least one obscure asymmetric cipher is provably immune to all known quantum computing attacks:
http://www.technologyreview.com/blog/arxiv/25629/
-Robert Rohde
On Thu, Aug 19, 2010 at 8:20 PM, Tim Starling tstarling@wikimedia.org wrote:
In a past life, I was a PhD student working on a broad military-funded project which aimed to break all known asymmetric cryptography schemes using large, expensive machines known as quantum computers.
There are more than a few asymmetric cryptography schemes that aren't known to be breakable by quantum computer. The popular ones (RSA, Diffie-Hellman) are all known to be breakable, though.
On Thu, Aug 19, 2010 at 11:06 PM, Tim Starling tstarling@wikimedia.org wrote:
Well, a GPU is fast because it is massively parallel, with hundreds of cores. Each core is typically slower than a CPU. I chose a function which is non-parallelisable, so you'd expect computation of a single hash to be slower on a GPU than on a CPU. But a GPU can calculate hundreds of them at a time.
Yeah, and attackers don't care about latency. They care about throughput.
On Fri, Aug 20, 2010 at 8:16 AM, Tgr gtisza@gmail.com wrote:
That is true for regular accounts, but with administrator access you can run malicious javascript on a large number of machines or track the visitors of a certain article.
Correct. As I said, we should absolutely be requiring secure passwords for admins on all projects. Upon promotion, the user should be required to re-enter their password before they get access to elevated privileges, and change it if it's not secure enough.
A totalitarian government going after checkuser access is not an unimaginable scenario either.
We're unlikely to be able to foil a totalitarian government of any size. They can do things like intercept any connections to the site, providing a forged certificate for HTTPS via a CA they control, and steal passwords or cookies. They might even be able to reroute arbitrary traffic through their borders by serving false BGP information or something (I don't know enough about that to say). But they probably don't care that much about all of this, because they don't actually need things like evidence to bash down your door and execute you for treason.
That said, the two things that would make the most difference (and are also much easier to implement) are SSL and password strength requirements. There is no point in fancy stuff like SMS or asymmetric cyphers which would be much more disruptive, a lot harder to introduce, and would have less effect.
We should definitely have HTTPS forced on for logins. And we should definitely have password strength requirements for admins.
Not to disagree with your general point, but that specific problem would be easy to handle by throwing a dialog with big red exclamation marks saying "WARNING! Arey you REALLY sure you know what you are doing?" when one is about to turn on such a feature. (Or only showing the controls when the user selects "expert mode".)
"Are you sure?" dialogs are terrible UI. Users will often click through without reading them, or cancel without reading them, or read them and not understand them, or click the wrong button by mistake. Plus they're really annoying, since they interrupt what you were trying to do. It makes much more sense to remove the option and let people use the API or custom JavaScript or a browser extension if they want to use an external editor.
On 8/20/10, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
They can do things like intercept any connections to the site, providing a forged certificate for HTTPS via a CA they control, and steal passwords or cookies.
See this: https://bugzilla.mozilla.org/show_bug.cgi?id=542689
Liangent wrote:
On 8/20/10, Aryeh Gregor wrote:
They can do things like intercept any connections to the site, providing a forged certificate for HTTPS via a CA they control, and steal passwords or cookies.
See this: https://bugzilla.mozilla.org/show_bug.cgi?id=542689
The solution would be having https://bugzilla.mozilla.org/show_bug.cgi?id=501697 implemented, and then restricting country CAs to their ccTLD. Although, as expressed on their bugzilla, if the country ccTLD passes the global trust requisites, cutting them wouldn't be too fair.
wikitech-l@lists.wikimedia.org