jeff at opendbms.com
Thu Feb 24 19:59:50 MST 2005
Well that's what's clever about this _HASH_ scheme is the seed is unique for each request, sent by the server. Of course a certificate is better but in this case it offers a decent level of protection from http sniffers where none was previously available.
On Thu, Feb 24, 2005 at 05:59:40PM -0700, Mac Newbold wrote:
> Today at 2:31pm, Jeffrey Moss said:
> >some pretty awesome uses too, like I did a site that didn't have a
> >security certificate and I set it up to encrypt the password in md5 before
> >you can get that on the web. I think Hotmail and Yahoo mail both use this
> >for their non-ssl login page.
> Sending a password hash insecurely usually means that (unless it's salted)
> it can be cracked using a dictionary attack, like those at
> http://www.passcracking.com . See earlier list discussions on the topic,
> and an article on the uphpu.org web site.
> The other thing that many people who set up something like that do not
> realize is that if they see your password hash (since it's being sent
> insecurely), they can use it to log in. They no longer need the actual
> password to log in, just the hash, since that's what your page expects to
> see. So you've just made it a different "password" they need to get in,
> but one that is just as easy to see as a plaintext password sent over http
> would be.
> Also, for correctness sake, you're not "encrypting" the password in md5,
> you're hashing it with md5. Encrypting is a process that can be reversed
> via decryption to yield the original text. MD5 is not such an algorithm,
> since it was designed to be hard to reverse. Encryption algorithms will
> almost always make use of a key (or a public-private key pair) to do the
> encryption and decryption.
> SSL is true encryption, and does use a key to encrypt the data before its
> sent, then the same key is used to decrypt it at the other end, getting
> back the actual bytes that were transferred originally.
> The curious may ask "But how do my browser and a web server agree on a key
> to use, without having talked before, or arranged it in advance, and
> without having anyone watching be able to know what the key is?" That
> would be a good question to have. The answer is something called the
> Diffie-Hellman (sp?) technique. It lets two entities set up a shared key,
> even if all their communication is visible by the attacker. That technique
> is the initial part of SSL, as well as SSH communications and I believe
> TLS as well.
> >As for the form action being parsed on the fly, sometimes it is necessary
> >when you have two different forms on one page and you need a little of
> >both. This is a problem with the original form specs not being flexible
> >enough for some things, like if you have an iframe with a form in it, and
> >you need to include some data from outside the iframe, you might either
> >have to insert variables into the form or re-parse the action string.
> >They're mostly hacks, but I'd hardly call that validation.
> No, they're not validation, but they suffer most of the same problems.
> that having an iframe in a page try to change form values in the
> surrounding page, or vice versa, is not a good idea. I don't fault the
> specs for not being "flexible" enough to allow it.
> >One of example of this off the top of my head that I find very useful is
> >this: www.realtor.com, when you type in some parameters and click
> >"advanced options", it captures everything you've already selected and
> >uses that on the advanced options page, which is extremely convenient for
> would say they've done it wrong. Prefilling is dandy, but it should be a
> >at all, and that is one of the best user interfaces I've seen. Same with
> >Google suggest.
> I've not used either of them yet. Same for gmail... it _requires_
> _at_all_, but I would expect that performance would be degraded, and some
> features probably unavailable. There are some times where it's a hit
> you're willing to take, but many people IMHO take that hit way too
> the main point of your UI, then it might be difficult to impossible to
> replace that functionality without it.
> >to the site by spiders? I dont want spiders going into order pages...
> Agreed. That's why the spider/robot thing isn't such an issue with
> on your pages.
> >unless I had a site with some sort of navigation gizmo that did funky
> >the site. Can spiders access popup screens? I bet some are designed to
> >spider I wouldn't want it to trace into form actions.
> popups can be troubling to a web spider. I would assume that the simplest
> depend on it. On one of my sites where it mattered a lot, we used the
> get_browser()/brower.ini stuff in php to check the User Agent string and
> determine if it was a bot or other non-js browser. When it is a non-js
> browser, all of the window.open("") popups become <a target=_new href="">
> links instead.
> >out there are going to make extensive use of it.
> I can understand that, and to a degree, I think a lot of good sites will
> make use of it. As we've already seen a lot of bad sites (and sites that
> an extremely portable medium (HTML) and robs it of many of its virtues,
> much like Microsoft and Internet Explorer have tried to do to HTML and the
> Internet in general. ;)
> Mac Newbold MNE - Mac Newbold Enterprises, LLC
> mac at macnewbold.com http://www.macnewbold.com/
More information about the UPHPU