Secure Logins

Hey, that's a good idea :)

Wed, 25 Jan 2006 at 20:44:35 GMT Link

Excellent suggestion!

Wed, 25 Jan 2006 at 20:50:50 GMT Link

What about when you don't use the mouse and hit enter to submit the form?

Isn't this why the default dialog of "You are going to submit data over a secure server" appears when submiting a form, that we all blindly automatically skip on?

A visual notification would be nice however, but a yellow padlock upfront provides no guarantee that the SSL certificate is valid :(

Wed, 25 Jan 2006 at 20:50:52 GMT Link

This was covered in a Security Now podcast (http://www.grc.com/sn/SN-020.txt

-- search for "I have a question about secure web pages")

Like Gibson or not, this is a real problem. My mom knows to use the "secure" version, but she doesn't know how to check.

Especially if the FORM is on a secure page and it posts to a non-SSL page.

I smell a greasemonkey script.. (-:

S

Wed, 25 Jan 2006 at 20:55:11 GMT Link

Have a look at this tweak in one's userContent.css:

form[action*="https://"] input[type="submit"],

form[action*="https://"] input[type="image"] {

cursor: crosshair;

}

Using a url() to a custom cursor file on a remote server seems to be denied by Firefox. But it's possible to set a different color and so on for the button... quite nice, at least until someone really creates a Firefox extension (or a Greasemonkey User Script) for this ;-)

Wed, 25 Jan 2006 at 21:52:06 GMT Link

The only problem with this is that that form wasn't necessarily served over TLS, and thus cannot be trusted, being vulnerable to a variety of tricky Javascript injection attacks.

Wed, 25 Jan 2006 at 22:00:30 GMT Link

You can't trust the action of a form, a javascript function could easily change the action when you click the submit button.

Wed, 25 Jan 2006 at 22:55:48 GMT Link

not a plugin we all want it built-in

Thu, 26 Jan 2006 at 07:23:29 GMT Link

And then we have to wait untill someone generates a javascript overlay that gives users the false impression they are submitting with https...

Thu, 26 Jan 2006 at 10:13:34 GMT Link

It'd be a nice idea... :)

Thu, 26 Jan 2006 at 11:12:42 GMT Link

I'm just glad I don't have to click twice every time I login to yahoo now. :)

Thu, 26 Jan 2006 at 15:44:01 GMT Link

those css selectors fpr html attributes won't work with IE:

form[action*="https://"] input[type="submit"]

:-/

Fri, 27 Jan 2006 at 20:12:23 GMT Link

Take a look at:

http://blog.phpdoc.info/archives/32...easemonkey.html

S

Sat, 28 Jan 2006 at 23:05:28 GMT Link

This Firefox extension kinda does what you are talking about

https://addons.mozilla.org/extensio...ication=firefox

Mon, 30 Jan 2006 at 04:13:20 GMT Link

Nice piece. I've always thought that one of my clients would throw a fit that you're working on a non-secure form, or that you're getting the "Submitting to a secure site" warning. They have done the latter and I've had to move the secure entry point to the very beginning of the process (e.g. as soon as someone enters a catalog), so that the warnings are distant memory by the checkout. Launching anything from your client to a secure server is good. What gets me are the scripts that make the round trip with the data and come back with errors and all of the data you submitted without SSL. If you submit to a secure site and you come back with the errors and you're in a secure environment, why not start in a secure environment with the initial form? That's a rhetorical question. :)

If the CSS custom cursor worked across the board ( http://www.w3schools.com/css/pr_class_cursor.asp ), that would be a good way to go to put a lock on the screen.

Another way would be swap the submit button and some of its surrounding space for a Flash movie. When you mouseover the button (read: movie), it hovers a lock icon at the tip of your point. When you mousedown, it submits that form. Then put in a <NOSCRIPT> with a plain-jane submit button, just in case.

Mon, 30 Jan 2006 at 17:25:01 GMT Link

I am a little confused.

I understand that if the form is on a http:// page BUT submits to a https:// page (ie named in the action attribute) then the form data is transmitted over the internet in an encrypted form.

However, what about the situation where the form is disdlayed on a https:// page but the file named in the action attribute is at a http:// address: My understanding is (?was) that as the form itself is on a secure page (ie with the https:// in the Address box and the closed lock icon in the status line) then when the Submit button is clicked, the form data is transmitted over the Internet in an encrypted format. Is this correct? My understanding is that the file named in the Action attribute was just a "form handler" which processed the data in the page. So I thought that the data would be submitted over the Internet encrypted, then is decrypted at the server, then the form data passed to the "form handler" and processed according to the code in that file. Now, as long as the data was not displayed back to the user then no data should have been sent unencrypted over the Internet.

Could you please advise? Thanks.

Sun, 12 Mar 2006 at 15:02:52 GMT Link

Probably a bit off topic, but I scratched my head so long on this one, that I had to share with as many boards as possible.

There is a Microsoft IE glitch that will not POST data from a form that consists of only one field (ie one text field) if the user hits enter instead of clicking Submit button.

Try it! Pissed me off for hours, until I finally found a microsoft development board that confessed to the crime!

There is not a real fix, just a hack or two: the one I used is making a second hidden text field. But to make matters worse (!) you can't just use a hidden form field element (ie type=hidden) you have to use type=text and add style= "visibility: hidden" for it to work.

Then (AND ONLY THEN) will the form actually post data from a submitted form with only one input element if the user hits enter.

Hope this saves some lives.

~ Ugh

Sat, 15 Apr 2006 at 22:40:06 GMT Link

Following on from a few comments made so far:

Can any form served over http that submits to https

really be considered secure?

I've been reading a few blog posts about this that

argue that http form to https submission isn't much

better than the whole thing just being in http.

E.g.

http://blogs.msdn.com/ie/archive/20.../20/410240.aspx

Because the original http form can be tampered with

(e.g. the action changed to a malicious https server)

it is not at all secure. Yahoo would come into this

category.

Thoughts anyone?

Hugo

Tue, 23 May 2006 at 11:34:44 GMT Link

Thanks for the reply Chris.

So basically then, http submitting to https is better than nothing, but is weak(er) security compared to full https

transmission (that banks and the like should be using).

Great blog by the way, I have been reading for

quite a while now and have learnt lots.. :)

Wed, 24 May 2006 at 19:53:05 GMT Link

I bank with Chase (www.chase.com) and they force you to login from a non-ssl page - or - at least I cannot find a page that is SSL to login from.

Typing in https://www.chase.com only redirects you back to the non SSL page.

Mon, 18 Sep 2006 at 04:10:14 GMT Link

Excellent piece! A visual notification would be nice. It is good don't have to click twice every time - login to yahoo now.

Thanks.

Wed, 15 Nov 2006 at 02:31:03 GMT Link

I for one am really tired with those yahoo savings and that they are generally accepted :(

Thu, 16 Nov 2006 at 15:56:43 GMT Link

Good suggestion for those with two users on one pc...

Sun, 19 Nov 2006 at 18:46:17 GMT Link

This idea about the visualization sounds really interesting. I think many users would be grateful if somebody would put it into practice.

Fri, 24 Nov 2006 at 16:31:17 GMT Link

Is anybody going to realize this great idea? ;)

http://ice-studio.com.ua/

Fri, 24 Nov 2006 at 16:34:49 GMT Link

I think that Yahoo is doing a great job with constant improving of their software. No matter how simple it may seem, it is a vital solution for the security of the system. Keep up the good work Yahoo!:)

Sun, 24 Dec 2006 at 12:25:07 GMT Link

very good idea, thank you!

Thu, 04 Jan 2007 at 16:42:49 GMT Link

The graphical lock implies security indeed, at least to the average users who can't notice what https represents. It's really a nice idea.

Sun, 28 Jan 2007 at 08:30:03 GMT Link