Re: Proposal for Lite Encryption for Login Form without SSL

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...@xxxxxxxxxxxxx> wrote:
klenwell wrote:
On Oct 1, 6:38 pm, Jerry Stuckle <jstuck...@xxxxxxxxxxxxx> wrote:
klenwell wrote:
On Oct 1, 2:40 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@xxxxxxxxx> wrote:
On 1 Oct, 06:04, klenwell <klenw...@xxxxxxxxx> wrote:
On Sep 30, 9:08 pm, Jerry Stuckle <jstuck...@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • RE: WSE_SmalQuestion
    ... Imagine the front door to my house. ... you will encrypt the message ... The SOAP message parts specified in the child element of the element are ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Proposal for Lite Encryption for Login Form without SSL
    ... javascript) to encrypt the password on my end and send it. ... Not if you're careful with the session salt - its unique to the ... Similar to locking your door and then leaving the key under the door ... SSL is secure and requires no programming on your part to implement. ...
    (comp.lang.php)
  • Re: [Full-disclosure] Introducing TGP...
    ... enemy has symmetric compute capability to yourself. ... opening the door to them using some hyper-core, ... encrypt a scan of your passport and post that. ...
    (Full-Disclosure)
  • Re: RFC: backporting GEOM to the 4.x branch
    ... > would be addressed by this, but wouldn't require replacing AES entirely. ... > cipher with a 64-bit blocksize), one should never encrypt more than ... Regarding the threat model - imagine an attacker sending you a number ... Algebraic attacks on AES show that AES may indeed be broken sooner than ...
    (freebsd-hackers)
  • Re: Infinite One-Time Pad, is this product BS?
    ... Selective brute force, ... You type a passphrase and strengthen it by running a sha-256 ... if you want to encrypt one file, ... the attacks on GnuPG that are most likely to succeed ...
    (sci.crypt)