I recently switched to Firefox and it warns me that my log in details "can be read by anyone" when I log into the Forums. Even when I used IE, it told me that the "Page contains non secure information" or some such.
It is entirely plausible, since the URL on the page where we log in is "http" and not "https".
Can I please get an official reply on this ?
.
.
Comments
Actually, the login system probably isn't secure because it's tied to IE. The launcher's dependency on IE is probably the biggest barrier to there being an official Mac OS X client there is, since it's easy to run it on Mac OS X with Wine and a hack to install IE....
IE= the best argument against embedding a web browser into an OS's UI that will ever exist... Active X (ie: Microsoft's first big "java killer") was probably the only worse idea they ever had, ie: allow websites to RUN CODE IN WINDOWS by default... Want to know why all us IT people have to spend 2/3rds of our time removing spyware from PC's? IE embedded as Explorer and Active X...
STO's launcher should instead be based on Firefox or even Chrome. Only pure laziness has it based on IE.
IE= the Typhoid Mary of web browsers.
Our launcher seriously needs redesign.
As I stated in another thread, news updates are better done using a web template based system. it's quicker to update than having to write new appended txt files. Also this isn't exactly new technology. MMO's have been using web embedded launchers for years now
LOL
I remember when FUD was a binary in Apple DOS :eek:
http
and not
https
I am not really tech savvy, I just heard that the difference between the two is one is not secure (http) and the other one is (https). I am sure you are right, but could you please put our concerns to rest why or how this turns into a secure login on a "http" page?
Am sure this is a case of knowing a little being worse than not knowing anything at all, but still would be great to know that this detail is either irrelevant for some reason or there is something else going on to make it "secure" ...
.
I am offended by you accusing me of trolling. Take that back, sir. I help pay your salary.
You still run on the engine.
You are still DEPENDENT on the engine. Which leaves you vulnerable to bugs in the engine. Which are too legion to list in less than 1,000 pages. Need I also mention the DOZENS of rootkits that hack and exploit IE's many bugs that are responsible for most of the botnets that are out there?
Get rid of MSHTML and stick with HTML, which is browser agnostic, if you want to truly claim security.
MSHTML isn't any sort of a standard. And there isn't any real reason to be tied to it, other than you wish to insist that IE (with all it's insecurity) be invoked when launching STO.
Changing to the Mozilla/Firefox engine would not only make STO more compatible, it would make it more secure.
Learn it, live it, love it ;-)
This makes no sense. What you are saying, essentially, is that you need to execute something on a PC just to show your launcher pages.
Which, yes, you can do with MSHTML using IE because it's an application that is installed on EVERY Windows PC by default since Windows 95 SR1, because IE is Explorer.
So, you are taking the lazy way out, instead of writing your own self contained launcher, you are taking a shortcut by defaulting to IE. Even SOE does better than that. And you have no idea how much it hurt me to say that.
From a web page argument, you have nothing to stand on with respect to using MSHTML vs HTML 4 or 5 (which is a standard, unlike MSHTML which isn't any sort of one). HTML displays in anything. Including IE.
What you are arguing is you need MSHTML so you can make OS calls from it. Which Gecko can't, nor can chrome. God bless em, that's why I use them! I don't WANT my web browser controlling my computer. I don't use IE. I use a heavily fortified Firefox that mostly doesn't run flash or javascript. This is why I don't actually NEED active antivirus on my PC...
It doesn't show as HTTPS in the stunted IE browser window.
And HTTPS is only as secure as the certificate and the server it is tied to. What kind of certificate do you use? What kind of server? If it's IIS (which it is almost certainly, given your MSHTML dependency), I can tell you it's INSECURE no matter what encryption you use, as it's susceptible to every IE, Explorer, and Windows rootkit and exploit there is out there. Zero day exploits to IE are reported every week, seemingly.
I am not saying that `Unix, Apache, and Mozilla are perfectly secure, but that they are MORE secure in structure than Windows ever will be unless fundamentally redesigned.
(I was kind of worried about this since day one using Internet Explorer, but Firefox's warning message was just scarier when I switched over)
.
You still haven't described your launcher's standard for a SSL certificate. For all we know it's self signed, since your launcher program controls everything we see...
Didn't we have this thread last week?
You're right; it's a program. You just said the equivalent of "get rid of your Craftsman hammer and stick with hitting nails with a heavy object with a handle and a flat head".
Nor should he have to. It's none of your business, nor anyone else, outside of Cryptic's development team.
If you were as expert on security as you like to make people believe, you'd know that the less information you give away, the less likely someone is going to hack your system.
I certainly agree that there's no need to invite malicious folks in and give them a tour, but a somewhat orthogonal point would be that obscurity is not security.
Responding specifically to the information requested by wildcat84 (self-signed, encryption strength, etc...), however, that can all be gotten by anyone willing to sift through a little network traffic for the missing pieces. By the nature of SSL, I would argue that it is indeed the business of anyone trying to connect to an SSL-wrapped service to be able to trust the remote endpoint. Information crucial to establishing this trust include (for this example) the requested website, i.e. launcher.startrekonline.com, a line of trust leading back to a trusted signatory, i.e. GoDaddy's Certificate Authority, and the strength of encryption available, which in this case is well more than adequate.
But i think its not so good that i can't load the gameclient directly (and thus log in)
My very own personal opinion is that a login client with less html would have been ok, but i'm not going to hold it against you.
(just my 2c)
So, you are using MSHTML because of it's embedded into Explorer nature it is able to EXECUTE code. Still not a good design. This is also how spyware/malware runs.
How's your intercept and keyspace defence set up? :P
Depends whether you got it right.
Common errors with custom protocols of this form:
- Failure to tie the authentication to a persistent session key, so session takeover attacks can be performed after authentication completes. TLS renegotiation attack, I'm looking at you. Sheesh.
- Failure to authenticate the server before the client, allowing man-in-the-middle
- Failure to authenticate the server against the session key, still allowing man-in-the-middle despite thinking you fixed it
- Use of a predictable nonce, such as the time
- Use of a nonce which is transmitted in the clear
- Use of a nonce which is not authenticated against the session key (hint: the nonce should probably include the session key, or maybe just be the session key; that also completely prevents replay attacks)
- Allowing the client to select the nonce
- Use of a nonce which contains less entropy than the size of the hash
That last batch all permit partial or full recovery of the key material from the ciphertext - worst possible failure case and most people get something wrong here.
Also, a common habit that adds no security but does break authentication on systems with unreliable clocks: including the client's timestamp in the hashed text. (Timestamp-based CR authentication wants the server timestamp in the challenge, not the client one in the response - but it's really not necessary, if your session key setup is good enough)
Minor aside: even if they were using TLS, it adds no security to use a CA instead of a self-signed certificate. That's a myth perpetuated by the CAs who want to sell certificates. What is important is whether anything bothers to verify the server certificate. TLS on the web is mostly a feel-good measure that adds no real security. It is possible to deploy TLS in a secure manner, but almost every website you encounter does not bother to do so; they are only using it to get that padlock symbol in your browser, and that's is all they care about.
Every browser is able to execute code. Stop spreading FUD.