|
|
Posted by C. (http://symcbean.blogspot.com/) on 10/02/07 12:53
If these posts get any longer we'll need to move to alt.binaries.php!
On 2 Oct, 11:33, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> klenwell wrote:
> > On Oct 1, 6:38 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> klenwell wrote:
> >>> On Oct 1, 2:40 am, "C. (http://symcbean.blogspot.com/)"
> >>> <colin.mckin...@gmail.com> wrote:
> >>>> On 1 Oct, 06:04, klenwell <klenw...@gmail.com> wrote:
> >>>>> On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >>>>>> klenwell wrote:
<snip>
>>>>>> Also, sending the password over an unencrypted link (even if the
>>>>>> password itself isn't encrypted) doesn't really give you anything. If I
>>>>>> want to hack into your system, all I need to do is watch the link for
>>>>>> the encrypted password coming over it, and create my own form (sans
>>>>>> javascript) to encrypt the password on my end and send it.
Not if you're careful with the session salt - its unique to the
session (done properly, unique to the request) therefore eliminates
the possiblity of replay attacks.
<snip>
> >>> Thanks for the detailed response, C. The user-specific hash is a good
> >>> idea. How do you execute the two stages? Does the user make two
> >>> submissions? Some kind of AJAX implementation?
Either would be valid (originally used 2 stage, then an iframe).
> >> Packet sniffing can be done anywhere between the client and the server.
> >> However, since every packet can theoretically take a different route,
> >> the most common sniffers are at the ends of the link.
>
I think you'd be surprised how easy it is to compromise systems with
ICMP redirection.
<snip>
> >> The question here is - why do you want to encrypt the password? Is
> >> there any reason you need it encrypted? What's on there that someone
> >> would want?
>
> > A couple reasons:
<snip>
> The point being - in some ways it's worse than having no protection at
> all. It provides a false sense of security.
>
> Similar to locking your door and then leaving the key under the door
> mat. It gives you a good feeling that you locked your door, but any
> smart thief (and even a few dumb ones) will look there first. It really
> doesn't give much more protection than leaving your door wide open.
>
> OTOH, SSL is secure and requires no programming on your part to implement.
One very good reason which klenwell didn't mention is this: that the
password itself may have more intrinsic value than the website and its
capabilities. I use different passwords for the services I use and
keep them all in an encrypted container - most users don't. There are
people out there using the same password for hotpr0n.example.com as
ultrasafe.securebanking.com
Sure having a totally secure logon does not solve problems in the rest
of the interaction (CSRF, XSS, Session Hijack....) but to say it has
no value is at best disparaging.
Similarly to say that non high-profile sites are not the subject of
the black hats intentions is also fundamentally misleading. Only high
profile sites have the resources to investigate or even detect
incursions, and of these, only a very small subset actually publish
information about attacks.
Regarding SSL - it is conceptually secure, but it is a very complex
system and implementations vary in quality. I've been lucky and only
been rootkitted once - guess how they got in?
C.
Navigation:
[Reply to this message]
|