>On Tue, 28 Aug 2012 18:56:03 +0000, TwoHoot wrote:
>
>> The__log_in_form_was_pre-filled_in_when_the_page_opened_ via the link on
>> we*****4u. The filled-in login form only appeared on one computer and
>> only arrived filled in when accessed from one outside link. Accessed in
>> any other way, the login form always arrives blank (so I can log into
>> the websites I maintain at different levels of permission to make sure
>> the right people can and can’t see the things they are supposed to see
>> or not see).
>
>With a password field, the only way that it would be pre-populated by the
>browser is with a saved password. Since you found the user ID and
>password in the saved passwords settings, at some point in that browser
>or another one that has its settings sync’ed, it would have been
>necessary to tell the browser to save the password.
>
>The password store is generally encrypted (I checked my own FF
>installation, and it’s a sqlite database that’s encrypted), so AFAIK only
>FF can actually change that file.
Sqlite is not encrypted, merely compressed. BIG difference. Much harder
to repair, no added security. Doubly detestable, for both wrong property
issues.
>
>I don’t think you have anything to worry about - the odds are probably
>that you inadvertently saved it at some point and just forgot that you
>had. I do that sort of thing on occasion myself.
>
>Jim
>On Tue, 28 Aug 2012 20:02:19 +0000, Will Honea wrote:
>
>> Jim Henderson wrote:
>>
>>> With a password field, the only way that it would be pre-populated by
>>> the browser is with a saved password. Since you found the user ID and
>>> password in the saved passwords settings, at some point in that browser
>>> or another one that has its settings sync’ed, it would have been
>>> necessary to tell the browser to save the password.
>>
>> That opens another question: If a form contains the password, is that
>> password saved (and re-displayed) as part of the form data? IOW,
>> can/does a saved form know enough to differentiate the password and is
>> the info stored encyrpted?
>
>Password fields are identified specially (so they mask the password as it
>is entered), and that authentication information is stored in a secure
>way (if you use a master password, it’ll be more secure).
>
>Jim
You sir, are way too trusting. In the windoes world many get compromised
that way. FF, chrome and opera are just as bad. Your choice. I read
comp.risks regularly.
On Mon, 03 Sep 2012 03:49:19 +0000, josephkk wrote:
> You sir, are way too trusting. In the windoes world many get
> compromised that way. FF, chrome and opera are just as bad. Your
> choice. I read comp.risks regularly.
On Mon, 03 Sep 2012 03:34:55 +0000, josephkk wrote:
> Sqlite is not encrypted, merely compressed. BIG difference. Much
> harder to repair, no added security. Doubly detestable, for both wrong
> property issues.
Looks like I was looking at a sqlite3 table with sqlite2, which is what
was saying it was encrypted.
I just dumped the content of “signons.sqlite” to take a look. It is a bunch of text records. But the passwords themselves appear to have been encrypted, and are showing as base64 encoded strings. Yes, I do use a master password.
The sites for which the passwords apply are visible in the file content. The passwords themselves are not. This is actually consistent with experience using firefox. I am not prompted for the master password until I visit a page that needs a password and for which the password has been saved. So firefox can recognize that the site is in the database, even though it cannot read the password until I provide the master key.
I’m adding this comment just to clarify what is in the sqlite file for passwords.
