I''ve been thinking about a way of transmitting something like username/password in a safe way over the internet. What I came up with was to either: A) Implement something like OpenSSH into my application. or B) Do it by letting the user open a webpage over a secure connection (shttp) and enter user/pass in a form, then store it along with ip on the server. When the game client connects to the server shortly after, the server sees the ip and know which user that just connected. While the "right" way of doing it probably would be to implement the secure transaction in the application, I''m still curious how to do B. Obviously, storing only the ip with the user/pass won''t work since many users can have the same IP (several computers on one internet connection), is there any way of uniqly identifying a computer so this scheme would work? If there is a way, would it be practical doing it this way? -Luctus

---

Statisticly seen, most things happens to other people. [Mail]

If there is a way, would it be practical doing it this way?

Hell no. This is Broken As Designed.

---

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan (C programming language co-inventor)

[edited by - Fruny on February 29, 2004 9:08:42 PM]

If they''ve opened a shttp connection, and they are submitting a form, why not have the result for submitting that form be some randomly generated 32 character password/token? The token would expire if not used within a certain time, and would only work for one session (if you closed the connection you''d need to login via shttp and get another). The token could be used as a simple password when connecting (since only you know the token, and if the token is sniffed it is useless since it can only be used once), or it could be used as a one time encryption key for that game session, making all the information passed to the game "secure".

Of course the proper way would not be to use a kludge like requiring an shttp connection before hand, but depending on the scale of your project you might not have the resources to impliment a secure SSH implimentation (OpenSSH has lots of resources, and look how many times its been hacked [with the results being worse then if the key had been cracked])

Anytime you separate authentication into a different application you open yourself to security vulnerabilities. I don''t think there''s any secure way to implement B. As you described it, there seems to be a man in middle vulnerability that would not exist if you used a direct secure connection to begin with.

Michalson: That's a good idea, and I would certainly consider it (if I ever get some time over to actually do some programming, that is ), but I was hoping for a more seamless way of doing it.

And yes, I thought of this solution because the idea of implementing SSH in a proper way into a (possibly future) application isn't very appealing..

-Luctus

---

Statisticly seen, most things happens to other people.
[Mail]

[edited by - Luctus on February 29, 2004 9:31:48 PM]

quote:

---

Original post by Luctus
And yes, I thought of this solution because the idea of implementing SSH in a proper way into a (possibly future) application isn''t very appealing..

---

While I have no idea how feasible it is, you could try using the OpenSSL libraries as opposed to open SSH. SSL is what https uses for securing a connection. The OpenSSL libraries are supoosed to be very good, and I believe OpenSSH uses the OpenSSL libraries for some of its functionality (the Crypto library).

You mean like RSA SecurID? http://www.rsasecurity.com/

-cb

Yeah, great suggestion. Forget the fact it costs around £50 per token and however much more for the licenses.

> Forget the fact it costs around £50 per token

I pointed out a secure two-factor authentication method. Forget the pricey token; use a PDA or a Java/Brew-enabled cellphone instead.

-cb