When will the forum use SSL?

[Dubslow]

1024 is not enough. The odds are that the N"S"A can break 1024 bit semi primes.

RSA as a whole probably isn't a good method anymore these days, even with bit sizes north of 4K.

[xilman]

Originally Posted by Dubslow

1024 is not enough. The odds are that the N"S"A can break 1024 bit semi primes.

RSA as a whole probably isn't a good method anymore these days, even with bit sizes north of 4K.

Your threat model is seriously broken if you believe that the NSA or their friends or their rivals would find it cost-effective to break kilobit RSA in order to compromise mersenneforum.org.

There are many, many cheaper ways. Just paying Xyzzy enough money would be orders of magnitude cheaper than factoring. Even if Mike's price is too high, it would still be cheaper to compromise the server's software and / or Mike's machine(s) and snoop his password or SSH private key, whichever he uses.

[Dubslow]

No, not here specifically, I was speaking generally. Kilobit RSA would likely protect us from those who would care enough to steal information, at least on that particular channel, but that doesn't mean it's a good idea no matter how easy the alternatives might be.

[mdettweiler]

Originally Posted by retina

Passwords are not really the issue. Cookie stealing and initial login hashes can be stored for later use. But unless the site suddenly becomes globally significant then I doubt anyone cares to go to all the effort for rewards that are essentially of very limit value. In short, don't worry about it.

FWIW...

Although our accounts on mersenneforum may not themselves be of particular value to an attacker (unless the user in question is in a position which people trust to publish software binaries on behalf of the project, as has been suggested ), the real threat in this sort of scenario is password reuse. In general, people re-use the same passwords between "important" and "unimportant" web sites. So, compromising a password through weak security (such as lack of encryption on login pages) on an "unimportant" site can lead to the compromise of much, much more important accounts. This is why you frequently hear in the news that some major website was "hacked", and then that website responds with a press release stating that they weren't hacked, the passwords were stolen elsewhere. These sorts of incidents are the long-tail "fallout" from past breaches. If you're interested in a more technical view of how this works, this article gives an interesting perspective on how attackers exploit this sort of thing.

Well-designed web sites only store hashes of users' passwords, which allow them to check whether the password sent by a login page is correct, without actually retaining the password in plain text for a hacker to grab and re-use elsewhere. This, however, does not entirely eliminate the risk (just reduce the attack surface in a big way). An attacker can still grab the password "in-flight" at the time of a live login, at one of three places: 1) the user's computer (e.g. through a keylogger), 2) on the wire between the user and the forum server (a "man-in-the-middle" attack), or 3) the server (by hacking the server itself and placing malware that reads passwords as they come in). HTTPS (SSL/TLS) encryption addresses #2 by end-to-end encrypting the password transmission from the user's web browser to the forum server.

Now, based on what yoyo noticed, it sounds like mersenneforum has its own "special" security measure which mitigates the lack of HTTPS somewhat. The login page hashes the password before sending it to the server, ensuring that a "man-in-the-middle" attacker only sees the hash, not the plaintext password. I am guessing that the forum is in fact double-hasing passwords, once in the client's browser before transmitting it to the server, and again on the server's end before storing/checking the password in the database. Most well-designed websites do the server-side hash (though shockingly many still do not); the client-side hash seems to be a special thing which we do here.

Keep in mind, though, that the once-hashed password is still good enough to get you into the user's mersenneforum account. This is necessarily so: the server has no way of knowing whether that once-hashed password actually came from a valid login, or from an attacker replaying a hash sniffed off the wire through a man-in-the-middle attack. So, without HTTPS to protect the transmission of the (once-hashed) password, a MITM attacker could steal a user's mersenneforum login credentials. This is, of course, not a very high risk (with the above-noted exception of a few users in special roles ).

The one big remaining hole is the possibility of actually cracking the MD5 hashes. Now, Dubslow mentioned that MD5 hashes are considered "crackable". This is true. However, there is a more useful (and simpler) attack than simply trying to come up with an MD5 collision (which would only let the attacker compromise the mersenneforum account - again, not very useful). A dictionary/"guided brute force" attack can crack hashes for "low-hanging fruit" (weak passwords) very easily, giving the attacker the original plaintext password - which is much more useful because it can be used to log into other websites where the password has been re-used. (That's assuming no other websites use the "double hash" trick like we seem to do here. If someone else also did a first-hash on the client side with the same algorithm we use - MD5 - then the stolen hash would be as good as the plaintext for logging into those websites. Only the server-side (second) hash is immune against the "good as plaintext" problem.)

Since people who re-use passwords between "important" and "unimportant" websites are also (one would assume) more likely to use weaker passwords in general, this makes the lack of HTTPS a real problem with viable attack vectors, even for "unimportant" sites like this forum.

The solution, of course, as many have noted here, is not to share passwords between "unimportant" sites that don't bother using SSL, and important sites where you can actually be damaged if compromised. Those of us who are savvy enough to even read a "When will the forum use SSL?" thread are probably doing this already. The problem is all the other users who aren't savvy about these things and who do reuse passwords with impunity. Whether this forum should take steps to actively safeguard those users is a decision for our dear forum admin and his lovable minions.

(we don't have a "TLDR" smiley???)

Frankly, the "big reason" why the forum should look into enabling HTTPS is the OP's point: Google is determined to stigmatize unencrypted HTTP over the long term by gradually ratcheting up the level of warning labels that the Chrome browser displays for unencrypted sites. Other browser vendors will undoubtedly follow suit.

Good arguments can be made for this position: as the OP mentioned, even just encrypting login pages is not enough, because besides the possibility of MITM attacks sniffing passwords, an MITM attacker could also modify the forum web pages in-transit, e.g. to inject malware into them. This is stopped by HTTPS because, in addition to encrypting the communications, it also verifies that it has not been tamped with in-transit. Any time a user visits an unencrypted website (regardless of whether he's entering a password or not) this is a threat. Hence, Google's war on the unencrypted Internet.

[LaurV]

Originally Posted by retina

Passwords are not really the issue. Cookie stealing and initial login hashes can be stored for later use. But unless the site suddenly becomes globally significant then I doubt anyone cares to go to all the effort for rewards that are essentially of very limit value. In short, don't worry about it.

Why, you should worry, I can take your password and substitute your smoker with my monkey...
A lot of damage! hehe

edit, eh, sorry, I didn't see your second post, you are right!

[Nick]

Originally Posted by mdettweiler

Google is determined to stigmatize unencrypted HTTP over the long term by gradually ratcheting up the level of warning labels that the Chrome browser displays for unencrypted sites. Other browser vendors will undoubtedly follow suit...Any time a user visits an unencrypted website (regardless of whether he's entering a password or not) this is a threat. Hence, Google's war on the unencrypted Internet.

But why is that a threat to Google itself?

[science_man_88]

I'm not sure MD5 is the best to use check out around the 5 minute mark of this video:

[mdettweiler]

Originally Posted by Nick

But why is that a threat to Google itself?

Ah, maybe I was unclear there. What I meant is, any unencrypted site that is part of your daily routine is a potential window of opportunity for attackers to hit you, because they can use a MITM attack to inject malware only on unencrypted sites. If (hypothetically) all sites moved to HTTPS - or at least, enough critical mass that the majority of Internet users only infrequently visited plain-HTTP sites - this attack vector would become largely unviable.

Now, from Google's perspective, this is not so much a threat (they already switched all their own sites to HTTPS a long time ago), as an opportunity. Security experts have been trying to make the case for a while now that more HTTPS on the Internet can only be a good thing. Google has invested a lot into building and maintaining a reputation as a trend leader in Internet security; by being the first to gradually ratchet up the "warning labels" their browser displays on unencrypted sites, they maintain that reputation of being "ahead of the curve".

Setting security aside, though, the important ramification for small, "unimportant" sites like this one is that if they don't get with the trend and enable HTTPS, they will eventually have problems with visitors being scared away by warnings in the browser. It's not just Google that's heading in this direction; I believe Mozilla has a similar roadmap for escalating the "minimum standard" for warning-free websites in Firefox. As for MS IE/Edge...OK, realistically they'll just continue to follow what the others do as a lame also-ran in the 2010s browser wars.

[bgbeuning]

Originally Posted by yoyo

The forum login page sends the password as md5 hash to the server. But nevertheless if the connection is not encrypted I can (as man in the middle) grep the user and md5hash and can resent it later to get a proper login.

If the MD5 hash is from using Digest Authentication mode,
then "replay attack" is not an issue because of the nonce used.
Each time you login, the nonce is different so the hash is different.
(The key assigned to an assignment by primenet is also a nonce.)

Digest access authentication

The wiki page says this use of MD5 is not as weak as general MD5 use.

[Xyzzy]

For the record, if we knew how to set the forum up for HTTPS, we would.

[ramshanker]

Originally Posted by Xyzzy

For the record, if we knew how to set the forum up for HTTPS, we would.

Any particular issue using Let's Encrypt? Try this one. https://certbot.eff.org/

Another vBulletin forum has already implemented the same.
https://killtube.org/showthread.php?...s-killtube-org