|
|
Posted by klenwell on 10/02/07 16:01
On Oct 2, 5:53 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.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.
>
> <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.
C.,
Do you mind outlining the iframe method you use?
Thanks,
Tom
Navigation:
[Reply to this message]
|