> specifically the ones that allow logins. Basically, a
> username/password is sent to the service and it responds
> with data if the person is a valid user. What stops
> someone from using the web service again and again to test
> a un/pw until they get the right one? Maybe the answer is
> obvious and I don't see it.
The answer may not be obvious, but this isn't a problem specific to web
services - it's true for any HTML forms-based login system. Unless you
specifically write code to deal with this problem, there's nothing to
prevent someone from sending HTTP POSTs until he gets the response he wants.
> checking amount of attempts per IP - ip can be forged
I'm not sure what you mean by this. If an HTTP request is coming from my
computer to your computer, the TCP/IP packets containing that request will
have the necessary information in them to allow your computer to respond to
mine. If that information is "forged", your computer will send the response
to the wrong address. So, no, an IP address can't be "forged" in any
meaningful sense, if I want to get any response at all. That's not to say
that an attacker couldn't generate requests from lots of computers already
under his control, of course.
> checking amount of attempts per UN - scheduled attempt
This is probably the most common way that people handle this problem, to the
extent that they bother with it at all.
> or multiple UN tries hidden communications key in stream -
> can be 'seen' (combined with SSL might work)
I'm not exactly sure what you mean by this, or why SSL would make any
difference. All SSL does is protect information while it's in transit from
point A to point B. If you're at either point yourself, the information is
completely exposed to you. So, it's trivial for an attacker to see the
"hidden communications key"; it may be less trivial for the attacker to
figure out what to do with that key, but this certainly wouldn't be a
reliable way to ensure security.
In fact, in some respects, using SSL can decrease security - if I'm managing
a network, I might use a traffic analyzer to see all the inbound and
outbound packets, but I won't be able to see what's going on in the ones
protected by SSL.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
