Password Manager

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Password Manager

David E. Ross-3
Bug #956906 was implemented to save passwords when autocomplete=off.
However, nothing was implemented to use saved passwords in that
situation.  This renders the implementation of bug #956906 useless.  On
top of that, the implementation broke the Remember Passwords extension,
which was an acceptable interim workaround.

Several bug reports have been submitted about this (e.g., #1025703,
#1064639).  What plans exist for addressing this problem?

--
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
<https://bugzilla.mozilla.org/show_bug.cgi?id=1064639>.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Justin Dolske-2
On 12/3/14 10:09 AM, David E. Ross wrote:
> Bug #956906 was implemented to save passwords when autocomplete=off.
> However, nothing was implemented to use saved passwords in that
> situation.  This renders the implementation of bug #956906 useless.

No, in general you can use the autocomplete dropdown to select a
username and the password will also be filled. (As bug 1064639 notes
that's a problem on pages without a username field, but that's also a
long-standing bug predating 956906.)

Justin

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

David E. Ross-3
On 12/3/2014 1:17 PM, Justin Dolske wrote:

> On 12/3/14 10:09 AM, David E. Ross wrote:
>> Bug #956906 was implemented to save passwords when autocomplete=off.
>> However, nothing was implemented to use saved passwords in that
>> situation.  This renders the implementation of bug #956906 useless.
>
> No, in general you can use the autocomplete dropdown to select a
> username and the password will also be filled. (As bug 1064639 notes
> that's a problem on pages without a username field, but that's also a
> long-standing bug predating 956906.)
>
> Justin
>

More and more financial institutions are modifying their login Web pages
to put user IDs on one page and passwords on the next page.  Three of
the four financial institutions where I frequently use the Web for
transactions already do this.  Thus, the problem is growing for Web
sites where passwords are especially important and where not having
passwords on PostIts or in plain text files is absolutely necessary.

--
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
<https://bugzilla.mozilla.org/show_bug.cgi?id=1064639>.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Philip Chee
In reply to this post by Justin Dolske-2
On 04/12/2014 05:17, Justin Dolske wrote:
> On 12/3/14 10:09 AM, David E. Ross wrote:
>> Bug #956906 was implemented to save passwords when autocomplete=off.
>> However, nothing was implemented to use saved passwords in that
>> situation.  This renders the implementation of bug #956906 useless.
>
> No, in general you can use the autocomplete dropdown to select a
> username and the password will also be filled. (As bug 1064639 notes
> that's a problem on pages without a username field, but that's also a
> long-standing bug predating 956906.)

ISTR there is a Greasemonkey script that creates a dummy username field
for you in such cases.

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

David E. Ross-3
On 12/3/2014 9:11 PM, Philip Chee wrote:

> On 04/12/2014 05:17, Justin Dolske wrote:
>> On 12/3/14 10:09 AM, David E. Ross wrote:
>>> Bug #956906 was implemented to save passwords when autocomplete=off.
>>> However, nothing was implemented to use saved passwords in that
>>> situation.  This renders the implementation of bug #956906 useless.
>>
>> No, in general you can use the autocomplete dropdown to select a
>> username and the password will also be filled. (As bug 1064639 notes
>> that's a problem on pages without a username field, but that's also a
>> long-standing bug predating 956906.)
>
> ISTR there is a Greasemonkey script that creates a dummy username field
> for you in such cases.
>
> Phil
>

Greasemonkey will not install in my browser, which is SeaMonkey.  In any
case, the use of an extension to compensate for the lack of a robust
implementation of am RFE should be considered to be only a temporary
workaround.  I would not call the implementation of bug #956906 robust
as it addressed only half of the underlying problem.

--
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
<https://bugzilla.mozilla.org/show_bug.cgi?id=1064639>.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Wesley Hardman
In reply to this post by David E. Ross-3
On 2014-12-03 16:37, David E. Ross wrote:

> On 12/3/2014 1:17 PM, Justin Dolske wrote:
>> On 12/3/14 10:09 AM, David E. Ross wrote:
>>> Bug #956906 was implemented to save passwords when autocomplete=off.
>>> However, nothing was implemented to use saved passwords in that
>>> situation.  This renders the implementation of bug #956906 useless.
>>
>> No, in general you can use the autocomplete dropdown to select a
>> username and the password will also be filled. (As bug 1064639 notes
>> that's a problem on pages without a username field, but that's also a
>> long-standing bug predating 956906.)
>>
>> Justin
>>
>
> More and more financial institutions are modifying their login Web pages
> to put user IDs on one page and passwords on the next page.  Three of
> the four financial institutions where I frequently use the Web for
> transactions already do this.  Thus, the problem is growing for Web
> sites where passwords are especially important and where not having
> passwords on PostIts or in plain text files is absolutely necessary.
>

I've been fortunate, not to run into this often.  I've never understood why this is supposedly "better".  The only thing it does is force me to write my password on a PostIt.

What I do see is a bunch of login pages that are completely script based, and often don't even have forms.  Most of these, though, are internal, device/service configuration pages.  I recall there being a bug related to this, but I can't seem to find it atm.  These are mostly just irritating, as they also usually have a very quick timeout, requiring you to login all the time.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Eric Shepherd
All my banks are like this now, as is my insurance company, my TV provider, my investment company, and a couple of others. It’s quite common. Drives me batty. :)

Eric Shepherd
Developer Documentation Lead
Mozilla Developer Network <https://developer.mozilla.org/>
Blog: http://www.bitstampede.com/
 <http://www.bitstampede.com/>Twitter: http://twitter.com/sheppy <http://twitter.com/sheppy>
> On Dec 4, 2014, at 5:51 AM, Wesley Hardman <[hidden email]> wrote:
>
> I've been fortunate, not to run into this often.  I've never understood why this is supposedly "better".  The only thing it does is force me to write my password on a PostIt.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Boris Zbarsky
In reply to this post by Wesley Hardman
On 12/4/14, 5:51 AM, Wesley Hardman wrote:
> I've never understood why this is supposedly "better".

The typical reason this is done is anti-phishing mutual authentication
systems, with a flow as follows:

1)  When setting up an account you select a username, password, and
image or other secret that both you and the financial institution know.

2)  When signing in, you type in your username but not your password.
Then the financial execution shows your shared secret.  If what it's
showing is correct, then you go ahead and type in the password.

The idea being that if you load a phishing page instead of the real
thing it won't be able to show you the right shared secret, so you will
know it's a phishing page.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Kartikaya Gupta-6
On 4/12/2014, 9:37, Boris Zbarsky wrote:

> On 12/4/14, 5:51 AM, Wesley Hardman wrote:
>> I've never understood why this is supposedly "better".
>
> The typical reason this is done is anti-phishing mutual authentication
> systems, with a flow as follows:
>
> 1)  When setting up an account you select a username, password, and
> image or other secret that both you and the financial institution know.
>
> 2)  When signing in, you type in your username but not your password.
> Then the financial execution shows your shared secret.  If what it's
> showing is correct, then you go ahead and type in the password.
>
> The idea being that if you load a phishing page instead of the real
> thing it won't be able to show you the right shared secret, so you will
> know it's a phishing page.
>

Except of course the phishing page can trivially act as a MITM and pull
the shared secret from the actual website based on the username you
enter. Never mind the fact that most people don't even notice/care [1].

kats

[1] http://en.wikipedia.org/wiki/SiteKey#Weaknesses

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Hubert Figuière
In reply to this post by Eric Shepherd
On 04/12/14 07:23 AM, Eric Shepherd wrote:
> All my banks are like this now, as is my insurance company, my TV provider, my investment company, and a couple of others. It’s quite common. Drives me batty. :)
>

Could be worse. You could have a password limited to just numbers[0] and
have to enter it on a randomly layout on screen keypad. [1]

Definitely, no password manager will help with that.



Hub

[0] Information entropy, anyone? Bueller?

[1] True and still current case. This after the bank told people to use
IE on windows because that the only browser they supported. And still
require Flash for some of the features, because HTML forms are insecure[2]

[2] no comment.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Gervase Markham
In reply to this post by Kartikaya Gupta-6
On 04/12/14 10:08, Kartikaya Gupta wrote:
> Except of course the phishing page can trivially act as a MITM and pull
> the shared secret from the actual website based on the username you
> enter.

Only if the URL to the shared secret is predictable given your username.
And there is no reason it has to be.

Gerv

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Gijs Kruitbosch ("Hannibal")
On 04/12/2014 14:38, Gervase Markham wrote:

> On 04/12/14 10:08, Kartikaya Gupta wrote:
>> Except of course the phishing page can trivially act as a MITM and pull
>> the shared secret from the actual website based on the username you
>> enter.
>
> Only if the URL to the shared secret is predictable given your username.
> And there is no reason it has to be.
>
> Gerv
>

I'm confused. If we're MITM'ing, we can take the user's input, send it
to the 'real' webpage, and scrape the secret from the returned page.
That input is guaranteed to get us the secret because it has to do so
for the original website if we weren't MITM'ing.

~ Gijs
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Boris Zbarsky
On 12/4/14, 2:56 PM, Gijs Kruitbosch wrote:
> I'm confused. If we're MITM'ing, we can take the user's input, send it
> to the 'real' webpage, and scrape the secret from the returned page.
> That input is guaranteed to get us the secret

So just to be clear, we are assuming and SSL MITM here, right?  One
which is getting to see the user's cookies and whatnot?

If we're positing that, then the user is pretty screwed.  The idea of
these image things is to handle cases when the user is being phished but
without a full-up SSL MITM.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Mike Hommey
On Thu, Dec 04, 2014 at 03:24:28PM -0800, Boris Zbarsky wrote:

> On 12/4/14, 2:56 PM, Gijs Kruitbosch wrote:
> >I'm confused. If we're MITM'ing, we can take the user's input, send it
> >to the 'real' webpage, and scrape the secret from the returned page.
> >That input is guaranteed to get us the secret
>
> So just to be clear, we are assuming and SSL MITM here, right?  One which is
> getting to see the user's cookies and whatnot?
>
> If we're positing that, then the user is pretty screwed.  The idea of these
> image things is to handle cases when the user is being phished but without a
> full-up SSL MITM.

No need for a full-up SSL MITM to MITM as kats suggested. The phishing
site can just act as a user agent submitting the username to the
original web site.

So, the user goes to the phishing site, submits username.
Phishing site submits username to original site and gets back the shared
secret.
Phishing site presents shared secret to user.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Boris Zbarsky
In reply to this post by Boris Zbarsky
On 12/4/14, 4:29 PM, Mike Hommey wrote:
> No need for a full-up SSL MITM to MITM as kats suggested. The phishing
> site can just act as a user agent submitting the username to the
> original web site.
 >
>
> So, the user goes to the phishing site, submits username.

OK.  But this does not have the user's cookies  The bank replies with
some text about "Either this is a new computer or you're being phished;
if this is a new computer please answer your security question".  See
http://en.wikipedia.org/wiki/SiteKey#How_it_works

Presumably the phisher then strips out the text and just presents the
security question bit which the user them might go ahead and just
answer.  The system is hardly perfect, nor even close to it, as kats
pointed out.  But it's also not as simple as just a simple replay on the
part of the phish site.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

David E. Ross-3
In reply to this post by David E. Ross-3
On 12/3/2014 10:09 AM, David E. Ross wrote:
> Bug #956906 was implemented to save passwords when autocomplete=off.
> However, nothing was implemented to use saved passwords in that
> situation.  This renders the implementation of bug #956906 useless.  On
> top of that, the implementation broke the Remember Passwords extension,
> which was an acceptable interim workaround.
>
> Several bug reports have been submitted about this (e.g., #1025703,
> #1064639).  What plans exist for addressing this problem?
>

None of the replies in this thread seem to answer my original question.

Are there plans to address the problem of using a saved password in a
login Web page that has autocomplete=off?  If so, is there a schedule?

--
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
<https://bugzilla.mozilla.org/show_bug.cgi?id=1064639>.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Gavin Sharp-3
We're kicking off an effort to improve our password management in
general, and bug 433238 and bug 348941 are likely to be considered as
part of that effort. I do not think we will address bug 1025703. For
future questions on this, you might get a better answer on
passwords-dev: https://mail.mozilla.org/listinfo/passwords-dev.

Gavin

On Tue, Dec 9, 2014 at 3:55 PM, David E. Ross <[hidden email]> wrote:

> On 12/3/2014 10:09 AM, David E. Ross wrote:
>> Bug #956906 was implemented to save passwords when autocomplete=off.
>> However, nothing was implemented to use saved passwords in that
>> situation.  This renders the implementation of bug #956906 useless.  On
>> top of that, the implementation broke the Remember Passwords extension,
>> which was an acceptable interim workaround.
>>
>> Several bug reports have been submitted about this (e.g., #1025703,
>> #1064639).  What plans exist for addressing this problem?
>>
>
> None of the replies in this thread seem to answer my original question.
>
> Are there plans to address the problem of using a saved password in a
> login Web page that has autocomplete=off?  If so, is there a schedule?
>
> --
> David E. Ross
>
> I am sticking with SeaMonkey 2.26.1 until saved passwords can
> be used when autocomplete=off.  See
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1064639>.
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

David E. Ross-3
In reply to this post by David E. Ross-3
On 12/9/2014 5:10 PM, Gavin Sharp wrote:
> We're kicking off an effort to improve our password management in
> general, and bug 433238 and bug 348941 are likely to be considered as
> part of that effort. I do not think we will address bug 1025703. For
> future questions on this, you might get a better answer on
> passwords-dev: https://mail.mozilla.org/listinfo/passwords-dev.
>
> Gavin
>

Is there a schedule for when this might be implemented, at least a
tentative schedule?

--
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off.  See
<https://bugzilla.mozilla.org/show_bug.cgi?id=1064639>.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Password Manager

Gavin Sharp-3
No, not yet.

Gavin

On Wed, Dec 10, 2014 at 10:40 AM, David E. Ross <[hidden email]> wrote:

> On 12/9/2014 5:10 PM, Gavin Sharp wrote:
>> We're kicking off an effort to improve our password management in
>> general, and bug 433238 and bug 348941 are likely to be considered as
>> part of that effort. I do not think we will address bug 1025703. For
>> future questions on this, you might get a better answer on
>> passwords-dev: https://mail.mozilla.org/listinfo/passwords-dev.
>>
>> Gavin
>>
>
> Is there a schedule for when this might be implemented, at least a
> tentative schedule?
>
> --
> David E. Ross
>
> I am sticking with SeaMonkey 2.26.1 until saved passwords can
> be used when autocomplete=off.  See
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1064639>.
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning