aboutsummaryrefslogtreecommitdiff
path: root/pipermail/nel/2001-April/000413.html
blob: ff93dba5cbd050a9b8fe4cdcecad5aace2372c78 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [Nel] A small document for your consumption</TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:archer%40nevrax.com">
   <LINK REL="Previous"  HREF="000411.html">
   <LINK REL="Next" HREF="000412.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Nel] A small document for your consumption</H1>
    <B>Vincent Archer</B> 
    <A HREF="mailto:archer%40nevrax.com"
       TITLE="[Nel] A small document for your consumption">archer@nevrax.com</A><BR>
    <I>Fri, 27 Apr 2001 17:15:17 +0200</I>
    <P><UL>
        <LI> Previous message: <A HREF="000411.html">[Nel] A small document for your consumption</A></li>
        <LI> Next message: <A HREF="000412.html">[Nel] 3dsmax 3.1 plug-ins</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#413">[ date ]</a>
              <a href="thread.html#413">[ thread ]</a>
              <a href="subject.html#413">[ subject ]</a>
              <a href="author.html#413">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>According to Brenden Towey:
&gt;<i> From: Vincent Archer &lt;<A HREF="mailto:archer@nevrax.com">archer@nevrax.com</A>&gt;
</I>&gt;<i> &gt; 3) MD5 for a dynamic challenge. A good example: the server sends you the
</I>&gt;<i> &gt; current date when you connect, and you use that date as the first
</I>&gt;<i> &gt; bytes of the MD5 digest.
</I>&gt;<i> 
</I>&gt;<i> Would #3 solve the login &amp; password hacking problem?
</I>
More or less. However, most of the hacking problems I've seen these days
on MMOGs do not involve a spoofed server or anything else. They're all
revolving around:

1) A scam aimed at getting your login and password
	(we have this incredible powerleveling service. Send us $30 and
	 your password and we'll have you level 50 in a month)

2) A trojan (last one on EQ pretending to be an 'undetectable macro
   program') that intercept the login/password pair when you *type them*.

Still, it doesn't hurt to make a MD5 challenge. If someone can spoof
you into believing you're talking to the server, the usual crypto layer
that protects your connection against sniffing will not protect your
password (something some web designers conveniently forget, saying that
once you're using https:// urls, you can send you password in clear to
the web).

&gt;<i> &gt;serves as authentification, and the WS then updates the LS with its state,
</I>&gt;<i> &gt;name and IP address. The WS may have a list of valid IP/port address for WS
</I>&gt;<i> &gt;to avoid the occasional pirate server registration.
</I>&gt;<i> 
</I>&gt;<i> 
</I>&gt;<i> Ok, I don't understand this.  Why would one person or company want to do
</I>&gt;<i> this?  What's the advantage to having a login service in one location and a
</I>&gt;<i> world service in another?  Why not just co-locate all your services behind
</I>&gt;<i> one firewall?
</I>
Bandwidth/Lag/Security issues.

Bandwidth is the first, and usually the less important one. But when you
start talking multiple OC12 links for your bandwidth consumption, you
quickly have limits on where you can locate your worlds. It is a lot easier
to negociate several locations with OC4 for each than say &quot;I need a place
with two OC12&quot;.

Lag is another one. All the world is not the states... tell it to the Aussies
who ranted and screamed till they finally got one Ultima Online server
down under. We're doing our best to make lag irrelevant, but given the
choice of playing on a server with 500 ms ping and a server with 100 ms
ping times... The experience with the latter will always be a *lot*
smoother.

And finally security. Not network security, I'm talking real security.
Despite every premium paid, what happens if your server room catches
fire, and despite generous smothering of Halon, all your servers are
burnt to a nice crispy taste? Sure, the insurance will pay you lots of
money. But your players will no longer be there.

Spreading your servers around makes sense on several points.

-- 
Vincent Archer                                         Email: <A HREF="mailto:archer@nevrax.com">archer@nevrax.com</A>

Nevrax France.                              Off on the yellow brick road we go!

</pre>

<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI> Previous message: <A HREF="000411.html">[Nel] A small document for your consumption</A></li>
	<LI> Next message: <A HREF="000412.html">[Nel] 3dsmax 3.1 plug-ins</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#413">[ date ]</a>
              <a href="thread.html#413">[ thread ]</a>
              <a href="subject.html#413">[ subject ]</a>
              <a href="author.html#413">[ author ]</a>
         </LI>
       </UL>
</body></html>