Posted by Jerry Stuckle on 10/02/07 14:07

C. (http://symcbean.blogspot.com/) wrote:
> 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.
>

That's true if it's a one-way encryption and the salt is changed every time.

> <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.
>

True, but to get the redirection you still need to be on a router in the
path between the client and the server. And the farther you get from
both ends, the less likely that would be.

> <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, I use different passwords for different things, also. But if
someone uses the same password for multiple sites, he shouldn't be
surprised if it gets broken.

> 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.
>

Not at all. It's worse than no value. It creates false security.

> 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.
>

I never said they weren't the subject of attacks. Read again. I said
they don't get in the news.

> 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.
>

Properly implemented, SSL is secure. Don't blame it for your lack of
normal diligence.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[Back to original message]