Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Password Manager File

3 views
Skip to first unread message

Boris Zbarsky

unread,
Nov 2, 2002, 7:46:34 PM11/2/02
to
TGOS wrote:
> I asked the question before, but never got any reply.

You may have better luck in n.p.m.crypto....

Boris Stanislavski

unread,
Nov 5, 2002, 3:04:03 PM11/5/02
to

>
> I asked it there three or four days ago and didn't get any reply. I
> already asked it there maybe two month ago and didn't get a reply either
> up to today. I don't know what I have to do to get a reply to such a
> simple question.
>
> All I'm asking for is information like this:
>
> "The key is the MD5 checksum of the master password, the encryption
> method is RC4."
>
> A single sentence like that would already tell me everything I need to
> know to.
>

if you're going to post with your real name and a valid e-mail address,
some more people could reply to your postings.

maybe this could be useful for you:
http://www.mozilla.org/crypto-faq.html


kind regards,

boris

Daniel Veditz

unread,
Nov 7, 2002, 8:28:34 PM11/7/02
to TGOS
TGOS wrote:
> On Tue, 05 Nov 2002 21:04:03 +0100 Boris Stanislavski <b5...@yahoo.com>
>
> No, they "can" reply to it right now and if they don't want, they only
> harm the Mozilla project, as then I will not write that app or write it
> for another browser instead and stop using Mozilla at all and discourage
> other people from using it either (because I can't promote a browser
> where I'm personally not convinced of and it was hard work enough to
> make all people I know stop using IE and switching to Mozilla).

Obviously the people reading this here are not the people who wrote that
code so we don't know the answer off the top of our heads. We could dig it
up, I suppose, but we're all too lazy to do the leg work for someone too
lazy to do it himself.

Look for the profile manager code in the tree (lxr.mozilla.org is your
friend). Do a "blame" and see who knows about that file. Mail them. Or
better, since they're probably busy fixing their own bugs, read the code and
find out what it does.

-Dan Veditz

Heikki Toivonen

unread,
Nov 13, 2002, 7:09:32 PM11/13/02
to
TGOS wrote:
> On Thu, 07 Nov 2002 17:28:34 -0800 Daniel Veditz <dve...@netscape.com>
> wrote in netscape.public.mozilla.security:

>
>
>>>No, they "can" reply to it right now and if they don't want, they only
>>>harm the Mozilla project, as then I will not write that app or write it
>>>for another browser instead and stop using Mozilla at all and discourage
>>>other people from using it either (because I can't promote a browser
>>>where I'm personally not convinced of and it was hard work enough to
>>>make all people I know stop using IE and switching to Mozilla).
>>
>>Obviously the people reading this here are not the people who wrote that
>>code so we don't know the answer off the top of our heads.
>
> Why can't there be a page saying "The key is MD5 checksum of the
> password and the encryption is Triple-DES"

Because nobody has had the time or whatever to write such a page.

> How many years does it take a developer to comment thousands lines of
> code with this single sentence that contains all information any
> developer will ever need? If people have time to spend a whole year on
> writing the code, they can spend *TEN SECONDS* to write a single line of
> text that explains how their code works.

And next time some developer comes along and *CHANGES THE CODE* the
*DOCUMENTATION WILL BE OUT OF SYNC*.

> How can anyone keep on writing any code for the Mozilla project if
> nobody knows anymore how what is working? Do the people managing the
> project expect programmers to read thousand lines of code to know how
> something works to then finally write the patch which is only ten lines
> of code altogether? So they waste three weeks on reading code to then
> write a patch in maybe three minutes. What kind of idiocy is that?

The best documentation is code. Sure, it can be harder to digest than
documentation, but the code is ultimately the only reliable piece of
documentation out there. Looking at the code can also give you a deeper
understanding of the issues, so you can write better code.

Of course we would like there to be accurate, comprehensive and up to
date information about everything related to the Mozilla project. And we
do have a lot of accurate information, and also a lot of obsolete
information. But we are not perfect, so there will always be areas where
there is no documentation or the documentation will be obsolete.

With Open Source you have the benefit that if there is no documentation,
you can go look at the source. With MS or Opera you don't have that
luxury. Closed source software houses often have documentation that is
in better shape, but they are not perfect either. I have had my fair
share of headaches with undocumented or obsolete Microsoft source and
documentation, for example.

What Dan was trying to explain was that since there is no documentation,
it is not the end of the world and you can go and look at the code. Dan,
or me, or just about anyone else could do that but why should we do it
since you can do it yourself? You are looking for free lunch, which
people generally don't like.

This cypro stuff is covered by the Mozilla crypto modules, most likely
by NSS or PSM. There is a web page describing that stuff at
http://www.mozilla.org/projects/security/pki/ I am almost certain that
PSM manages the password file, and uses NSS to do the encryption. Look
at the page for where this code is stored, so you can start digging.

Also this is crypto stuff, so the correct Mozilla newsgroup is
netscape.public.mozilla.crypto. Followup-To set accordingly.

PS. Since I don't know cypto I don't know if this is what you were
looking for, but if it is then what can I say (see the end of the
file)... http://people.netscape.com/lord/psm/n61/

--
Heikki Toivonen

Nelson B. Bolyard

unread,
Nov 13, 2002, 10:09:00 PM11/13/02
to
TGOS wrote:

> I don't expect any detailed information,

That's part of the problem.

Your original request, asking for a one-sentence description of how the
key was derived from the master password, was not answered because it had
no answer. The request is based on a false premise, that the key is
derived from the master password. The key is NOT derived from the master
password.

The system used to protect mozilla users' passwords is not the simplistic
crypto exercise that one might naively imagine it to be.

> I know everything I need to know except the encryption method.

Dubious. Read on.

> I have a string of data, that is
> encrypted and I want to convert it back to plain text. And I don't even
> have to "crack" anything, I know the master password (after all it's MY
> password) and have the encrypted string, that is all I need to decrypt
> it...

No, it's not.

> if I'd know which method to run over it and how to generate the
> key from the password.

The key is not generated from the master password, and cannot be derived
from the master password itself.

> Why can't there be a page saying "The key is MD5 checksum of the
> password and the encryption is Triple-DES"

Because it's nowhere near that simple. There are several levels of
indirection that you've not considered.

The key generation, storage, and related encryption and decryption is
all done inside of a cryptographic "token" (hardware device, or software).
The master password is used to authenticate the user to the token, after
which the token will do the necessary crypto on behalf of the user.

The crypto key is _randomly_ generated by and stored inside of the token.
When the token generates the key, the token outputs a key identifier that
identifies the key, but does not reveal the key. That key identifier is
used, instead of the key, whenever the user asks the token to encrypt or
decrypt data.

The base64 encoded blob you see contains an ASN.1 DER encoded structure
which contains the key identifier; another DER encoded structure which
contains the algorithm identifier (the system is not limited to any one
encryption algorithm) and the initialization vector (for block ciphers
only); and the encrypted data.

Even if you have decoded all that data and have the master password, you
do not have the key to decrypt the data. You must go back to the token
for the decryption because the token holds the keys.

> How many years does it take a developer to comment thousands lines of
> code with this single sentence that contains all information any

As you can see, one sentence cannot describe it. I didn't even begin to
describe the ASN.1 structures used, nor the means by which the keys are
protected and stored in the tokens.

Given that, by default, mozilla uses a software emulation of a hardware
token, it is possible to dig into the encrypted databases used for the
emulated token's storage and find and extract the keys, with some
non-trivial amount of work. It's far easier just to use the token via
the same API that mozilla uses.

If you want web pages that explain this, start with these:
http://lxr.mozilla.org/security/source/security/manager/ssl/src/nsSDR.cpp#158
http://lxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11sdr.c#254

Use the Source, Luke!
--
Obi-Wan
Disclaimer: I speak for myself, not for Netscape

Boris Zbarsky

unread,
Nov 17, 2002, 4:50:59 AM11/17/02
to
TGOS wrote:
> Pardon me, but what cryptographic hardware does Mozilla support? I'm not
> aware of any such support build into Mozilla.

We aren't talking about Mozilla. We're talking about NSS, which is the
crypto library used by Mozilla (and maybe about PSM). Mozilla's use of
NSS does not involve the use of a hardware encryption device by default
(PSM fills this need, if I understand things correctly), but NSS itself
supports this for other software which may wish to take advantage of it.

http://www.mozilla.org/projects/security/pki/nss/#Documentation and
http://www.mozilla.org/projects/security/pki/nss/faq.html provide more
information on what NSS is and what it does, including some more detail
about interfacing NSS with crypto hardware. They don't really cover the
sort of code-level details you're asking about, however.

> Unacceptable, because the app will not be written in C++ and must run on
> systems where Mozilla isn't even installed (as long as all the user
> profiles are installed, that should be no problem).

NSS is a standalone C library (not C++) that can be installed without
the rest of Mozilla being installed (since it's designed as a generic
crypto library, and not even mainly for Mozilla). I'm not sure whether
you'd also need PSM or not to do what Nelson suggests; PSM is,
unfortunately, in C++.

Nelson B

unread,
Nov 17, 2002, 7:03:27 AM11/17/02
to
TGOS wrote:
>
> On Wed, 13 Nov 2002 19:09:00 -0800 "Nelson B. Bolyard"
> <nel...@netscape.com> wrote in netscape.public.mozilla.security:

> > The request is based on a false premise, that the key is
> > derived from the master password. The key is NOT derived from the master
> > password.
>

> Then Mozilla crypto system is a very bad system.

Really!?

Let's see. The U.S. Government has put NSS (the crypto security module
used in mozilla and Netscape browsers) on their list of validated crypto
modules, meeting the Federal Information Processing Standard 140-1,
the Federal Security Requirements for Cryptographic modules.

It's on the same list with many other well known hardware and software
security modules. The U.S. Department of Defense uses it. They studied
it in depth. See for your self at these URLs:

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
http://csrc.ncsl.nist.gov/cryptval/140-1/1401val2002.htm (scroll down to #247)
http://csrc.ncsl.nist.gov/cryptval/140-1/140crt/140crt247.pdf
http://dii-sw.ncr.disa.mil/Del/netlic.html#products

The validation certificate is listed in Sun's name because Sun is one of
the major contributors to, and users of, NSS, and Sun sponsored the NIST
validation, I believe.

> > The key generation, storage, and related encryption and decryption is
> > all done inside of a cryptographic "token" (hardware device, or software).
>

> Pardon me, but what cryptographic hardware does Mozilla support? I'm not
> aware of any such support build into Mozilla.

Nearly every crypto hardware device that supports a PKCS #11 software
interface, version 2.x, works with mozilla. That's Public Key Cryptography
Standard Number 11, in case you're not familiar with it.
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/

Devices ranging from high end crypto accelerators down to little crypto
devices that fit on your key chain or in your wallet work with mozilla.
I have 3 devices on my key chain in my pocket, and one in my wallet, all
from different manufacturers, and all work with mozilla for signing email,
decrypting email, and authenticating to SSL/TLS servers.

NSS's crypto software emulates a PKCS 11 hardware token.

> > The base64 encoded blob you see contains an ASN.1 DER encoded structure
> > which contains the key identifier; another DER encoded structure which
> > contains the algorithm identifier (the system is not limited to any one
> > encryption algorithm) and the initialization vector (for block ciphers
> > only); and the encrypted data.
>

> And this is documented where?

The ASN.1 encoding, and the algorithm identifier OIDs used, are all
international PKI standards. Many are also documented in Internet RFCs.
See, for example, ftp://ftp.rfc-editor.org/in-notes/rfc3279.txt

If you were familiar with the relevant standards, you probably wouldn't
be asking this question. I suggest you start by studying the standards
and "related documents" listed on these pages:
http://www.mozilla.org/projects/security/pki/nss/overview.html#standards
http://www.mozilla.org/projects/security/pki/nss/nss-3.4/nss-3.4-algorithms.html
http://www.rsasecurity.com/rsalabs/pkcs/

> A security system that is only secure as long as the details stay a
> secret was never secure in the first place. A good security system is
> still secure even if all code is open and all implementation details are
> known to the public. The Mozilla code is open,

And therefore does not depend on secrecy. It's all wide open.
Don't be afraid. Have a look for yourself.

> Have the people that planned the security system never considered that
> other programs which are NOT part of Mozilla, which do NOT have access
> to the Mozilla libraries and which are NOT written in C++ may want to
> access Mozilla's stored user data?

Mozilla's NSS libraries are written in c, not c++, and are freely accessible.
NSS is used by many products not written in C++. See a list at
http://www.mozilla.org/projects/security/pki/nss/overview.html#proven

There is even a Java "reflection" available for it, known as JSS.
See http://www.mozilla.org/projects/security/pki/jss/

The desire for NSS to be usable by many other products is precisely why
mozilla's NSS security system uses an open standard API, the PKCS #11
standard, for access to all its data. NSS's PKCS 11 crypto module is a
dynamically loaded shared library, so an application doesn't need to link
with it to use it. See http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/

Netscape and mozilla have reserved the right to change the internal
implementation, including the database formats, without notice. They will
soon change again. But the APIs will continue to work.

> This still leaves my initial questions open:
>
> Which encryption method does Mozilla use to encrypt the database and how
> does it get the key to decrypt the database from the master password.

Those were clearly NOT your original questions. You've learned some more
about NSS, and you're asking new and more relevant questions now.

Have a look at http://www.rsasecurity.com/rsalabs/pkcs/pkcs-5/

> And if every encryption method has an ID, where is documented which ID
> stands for which method? And again it's lack of documentation.

The OIDs used to identify the crypto algorithms are all found in standards
that are will known to the community of crypto developers. Knowledge of
the relevant crypto standards is a prerequisite to working with NSS
internals and NSS data.

> See, I can't guess im which out of hundred source code file this might be
> written in a two-liner if it's written anywhere at all.

That's why mozilla's source servers have powerful source searching and cross
referencing capabilities. Look at them here http://lxr.mozilla.org/security/

> > It's far easier just to use the token via the same API that mozilla
> > uses.
>

> Unacceptable, because the app will not be written in C++ and must run on
> systems where Mozilla isn't even installed (as long as all the user
> profiles are installed, that should be no problem).

You proposed to write a program to manipulate mozilla user profiles, as a
supposed convenience to mozilla users. Now you say it must run on
systems where mozilla isn't installed? That doesn't sound very convenient
for mozilla users. Sounds fishy. I wonder if the program has another
true purpose.

> And that's what Mozilla programmers call documentation?

No, it's what they call source code.
The answers to all your questions are in there, starting at those lines.

Follow one of those links. Notice that many identifiers are underlined.
Click on of those identifiers. See how the cross referencing works.

> > Use the Source, Luke!
>
> Thanks for the links, but without any further documentation, I'm afraid
> it's quite useless.

Reminds me of an old saying:
You can lead a horse to water, but you can't make him drink.

> --
> TGOS

Now, I've written as much as I'm going to in this thread.

No one is obliged to keep answering demands for more explanation about NSS,
especially when the source is open. You're going to have to do some work
to understand what you're attempting to do. Read the source. Or don't.
But there's no point in complaining about open source.

People who have clearly studied the source and still have questions, and
who ask those questions without complaint, often get their questions
answered in netscape.public.mozilla.crypto. Followup there.

--
Nelson B Speaking only for myself.

Boris Zbarsky

unread,
Nov 18, 2002, 5:33:41 AM11/18/02
to
TGOS wrote:
> (and a quantum computer may be able to solve it pretty fast)

For the foreseeable future (next few decades, imo) this should be the
least of your worries. This is my personal opinion, of course, based on
a bit over a year of doing quantum computing research....

> OIDs are S/MIME Object IDs and MIME is a mail standard. Why is a mail
> standard used to encrypt webpage passwords?

What gave you that idea? See http://www.alvestrand.no/objectid/ (result
of a 10-second google search that seems to be fairly relevant). OIDs
can be used to refer to many things _including_ crypto algorithms.

> Doesn't matter.
> What if I want to write the code in a scripting language that can't
> access any external libraries?

It is your right to choose a language poorly suited to the task you wish
to accomplish, of course. No one is going to try to stop you.

> Just writing all data into a simple text-only or XML format and
> encrypting everything with Cast/IDEA/Twofish/Serpent, using a key
> generated as MD5 checksum of the master password will guarantee access
> to all of it's data by all kind of applications, scripts or whatever
> else without the need to be allowed to execute native code or to force
> people to first several thousand lines of code into the used language.

You're assuming the intent is to give people access to the data. On the
contrary, the intent is to keep the data secure. For example, the
method you propose is very vulnerable to dictionary attacks on the
master password. So a better method would be desirable.

Like Nelson, I feel I must bow out of this discussion, which is clearly
going nowhere... the fact that you didn't bother to do a careful search
on what OIDs are is pretty indicative, imo.

Ben Bucksch

unread,
Nov 19, 2002, 12:03:12 AM11/19/02
to mozilla-...@mozilla.org
TGOS wrote:

>Written on Mozilla.org (somewhere in the shameful little documentation
>about PSM or NSS).
>
TGOS, it's enough. You recieved more individual help here than I usually
get when I try to fix Mozilla bugs/features. You are not glad about
that, but continue to flame the Mozilla/Netscape developers.

And if *you* expect to be taken serious, then follow the charter of the
newsgroups you post to. Which would have meant to post with (real) name
and email address. This was pointed out to you, but you ignored it.

> No, I don't want to write software that depends on some external library
> to be present (which may not even exist for the platform it will run
> later on)

I wonder how the Mozilla profiles get on that platform, but anyways: You
probably know that NSS runs pretty much on all desktop and server
platforms in existance. I don't think your washing machine needs to read
your Mozilla password file.

> because one would need root privileges to add the library
> which a user just may not have, etc.)

Libraries don't need root priviledges to work. You can install them
aside to your binary, no uninstall hassles involved. In fact, you might
even be able to link it statically.

> What if I want to write the code in JavaScript and use a HTML page as
> GUI?

Aha aha ahaaa. JavaScript, HTML page. I smell something.

> I think no scripting language has a better cross-platform
> support as every platform that offers a modern browser can execute
> JavaScript.

Every platform I know that offers "a modern browser" can run NSS. Often,
Mozilla is exactly that modern browser, the only one.

>> You're assuming the intent is to give people access to the data.
>

> Yes. This is MY DATA. These are MY PASSWORDS. And, OMG, believe it or
> not, I want to have access to MY DATA.

First, it seems to me that you are contradicting yourself here. You
wrote before

"So PGP mails are only secure if you can always keep the key file (that
contains your private keys) secure, which is not the case if it's stored
on HD (a Trojan could access it easily)."

Ignoring for now that if you have a trojan onboard, you are lost
*anyways*. You appearantly want your data protected from that trojan,
but not from your self-written script (where does it run from? a
webpage?). Where is the difference, technically?
(Consider dictionary attacks on passwords and the fact that the vast
majority of Mozilla users doesn't have a master password. - Sorry, if I
mixed something up here, but I didn't follow the whole thread.)

Second: No, the passwords Mozilla stores for you are not your "data".
They are more in a cache. You are supposed to keep track of your
usernames/passwords somewhere else. This feature is only for convience,
to save you the repeated typing. Mozilla cannot garantee the level of
data security that would be needed to savely keep the only instance of
your online identity.

Keep the master database of your passwords in a PGP-encrypted file or
whereever. (Or tell the user to do so.) Which should also pretty much
end this discussion.

>> the fact that you didn't bother to do a careful search
>> on what OIDs are is pretty indicative, imo.
>

> Tell this the webmaster of Mozilla.org

Where does the site state that OIDs apply to S/MIME only?

Maybe a trivial, obvious Google search would help you?
<http://www.google.com/search?q=site:mozilla.org+OID>
Or the search function of the site itself?
<http://www.mozilla.org/htdig-cgi/htsearch?words=OID>


Thomas Dodd

unread,
Nov 21, 2002, 2:37:47 PM11/21/02
to mozilla-...@mozilla.org, TGOS

TGOS wrote:

>>>Doesn't matter.
>>>What if I want to write the code in a scripting language that can't
>>>access any external libraries?
>>>
>>>
>>It is your right to choose a language poorly suited to the task
>>you wish to accomplish, of course.
>>
>>
>

>No, I don't want to write software that depends on some external library
>to be present (which may not even exist for the platform it will run

>later on) or on the ability to access libraries at all, what's so hard
>to understand about it? Everything my software does must be done by the
>software itself (except the lowest low-level routines like file and
>network access, as well as the GUI if a GUI exists for a certain system
>at all).
>
>
You always have 2 choices here. 1) use the library, possibly statically
linking it, or 2) rewrite the needed parts in you app.
If you want to use X11 drowing call, you need the X libs. If you want
GTK+, use use the GTK+ libs (which need X11 too).
If you want GNOME use us ethe GNOME libs (wehich need GTK+ and X11). You
asking for the equivelent of a javascript GNOME API, that doesn't need
the GTK+ or X11 libs. You would have to write that yourself.

>It is poorly designed to write a software that relies on a library and
>then can't work on a system where this library is not present and also
>can't be installed (because the library doesn't even exist for the
>platform or because one would need root privileges to add the library


>which a user just may not have, etc.)
>
>

Then EVERY peice of GUI software written is poorly designed. Try running
a win32 program without the MS dlls. Or any GNOME app on a system
without the GNOME libs (like MS-Windows or MacOS). even QT, which has
MS-Windows libs, requires them to run, and those apps won't run without
them. On any system.

>>You're assuming the intent is to give people access to the data.
>>
>>

>Yes. This is MY DATA. These are MY PASSWORDS. And, OMG, believe it or

>not, I want to have access to MY DATA. Sounds revolutionary to you, but
>to most people it sounds plain logically.
>
>
Then store them is a system youy designed. Mozilla stores them in the
safest method it can. It wasn't designed to allow editing of that data.
However, it does use an open API to the crypto functions. You can
replace mozillas NSS modules with your own, and do what you want with
the data that module stores. That's the reason mozilla use a crypto
module method. To allow changes, like using a smart card reader, or
biometric module to be used. If you want, you can write a module that
stores the data in a plain text file with NO encryption.

Or at least you should be able to. I'm not sure that mozilla supports
that reassignment yet. I would like a smart-card or similar removable
storage device to hold passwords, and for that devices "master
psaaword" use a bimetric scanning device, like finger print or retina
scanning. An addon device for this with drivers and PKCS#11 modules for
most OS/hardware combinations would be great:)

>But not to keep it away of me. Right now it looks like Mozilla rates me,
>the person who provided it with these data in the first place, as
>insecure, because it doesn't even allow me to see my own data anymore or
>edit it.
>
>
Displaying that information on the screen is insecure. Someone could see
the screen/intercept the calls that draw the screen.
That's one of the reason X11 should not be used remotely with an
unencrypted transport (SSH tunneling is better), you can grab the X11
packets and display them on your screen. That lets you see everything
someone else displays and types.

-Thomas

Ben Bucksch

unread,
Nov 23, 2002, 8:16:52 PM11/23/02
to mozilla-...@mozilla.org
TGOS wrote:

>>And if *you* expect to be taken serious, then follow the charter of the
>>newsgroups you post to.
>>

http://www.mozilla.org/community.html

>If Mozilla has generated the data, it's still my data
>
>
Just like the processor cache. You can't access that either.

>You say the way I suggest isn't secure enough
>
No, I didn't. I said it's impractical.


Thomas Dodd

unread,
Nov 25, 2002, 11:12:49 AM11/25/02
to mozilla-...@mozilla.org

TGOS wrote:

>On 21 Nov 2002 19:37:47 GMT t...@cypress.com (Thomas Dodd) wrote in
>netscape.public.mozilla.security:


>
>>You always have 2 choices here. 1) use the library, possibly statically
>>linking it, or 2) rewrite the needed parts in you app.
>>
>>
>

>And I choose (2), because I can't link statically to a scripting
>language that isn't even compiled. And that's why I was asking for as
>much information as possible about the library Mozilla uses, because I
>will have to re-write it from the scratch.
>
>
You have as much info as needed. The entire NSS lib source code. Build a
debug version of mozilla, and run it iun a debugger. You'll see EVERY
function call, and all the data used/passed in the functions. If you
really want to help, once you figure it out, write up a 1 or 2 page doc
about the flow for other to use. You apperar to be the first to ask for
it, but likely won't be the last. Do you have the spirit of OSS, or just
want to leach off of it?

>>If you want to use X11 drowing call, you need the X libs.
>>
>>

>But if I write a X11 app, it's designed right from the start to ONLY run
>under X11 systems. Hence I'd never do anything that stupid if I know
>right from the start code has to run on non X11 systems as well.
>
>
Since X has been prrted to most OSes, there aren't meant non X11
systems. I run commercial X servers in M$, and
XFree86/cygwin is a fairly workable combination.

More to the subject, the mozilla developers, never intended the NSS code
to be used on non mozilla systems. They included support for other
methods to handle that, like smart cards. How long have you been
involved with the mozilla project? It fells like you just found it and
decided "this is what I want". Then you come along like you know all
there is to know about what should be done. The project was announced
widely, years ago. You should have joined then and helped shape the
future development. You can still do that. Figure out the call stack.
Write the code that does what you want. Post it as patches. Push for
inclusion. Can it be done as an addon, like the UABar was?

>Which it is! That's why I'm always strictly separating the *mandatory*
>CORE of the *optionally* GUI. If I want to support twenty of platforms,
>
>
Mozilla doesn't have and *OPTIONAL* GUI yet. The NSS lib and PSM code is
optional though. I can remove those packages and still browse the web,
ftp file, and read e-mail (just no SSL support). So write you own
replacement for that code, that is cross platform, scriptable, and
generaly does what you think it should.

>I thought it makes sense to store WEB passwords into a WEB BROWSER,
>after all that's the client that will need the passwords later on and
>that's the client that can pre-fill the passwords for me (something
>
>
And mozilla does that. You are asking to do something else.

>external software will never be able to do). Hence it would be very
>programmer friendly if programmers can easily pull passwords out the
>database and move new ones into the database, no matter what language or
>platform they use.
>
The hooks appear to be there. You just have to write the backend code to
sotor the data in the way you want. There's not a lot of language
neutral stuff out there. But it commiing. GTK/GNOME libs have C, C++,
and Python bindings, probably more. So write a perl-NSS binding.

>>Mozilla stores them in the safest method it can.
>>
>>

>No. It just uses the most complicated way it can, but it's not anymore
>secure than using a much simpler encryption method. Making things
>complicated (obfuscating data) is not making them any more secure.
>
>
It's not obfuscared. It's just part of a complicated system. Do you
think that PKCS #(5. 7, 11, and 12) support is a bad thing? Do you think
the ability to change the storage method is a bad thing?

>>It wasn't designed to allow editing of that data.
>>
>>

>But it should, because users want to change their own data. Useres want
>to move data from their profile on HD to a disk and then re-import them
>from the disk after a HD crash or move them to another profile on a
>different PC. Or to have two profiles and merge the passwords stored in
>
>
I agree here. And oncethe rest of the system is better, it will come. If
you want it sooner, do it. Nobody will complain. The problem is, once
you got the informatyion, instead of using it, you started critisizing
the developers and the system. This is OSS, where talk is cheap, and
CODE is the currency of choice.

>>Displaying that information on the screen is insecure.
>>Someone could see the screen/intercept the calls that draw the screen.
>>
>>

>And this wasn't possible when I entered the password for the first time
>and that way added it to the database?
>Sure it was. So what't the point of the statement?
>
>
Likely not. And depending on you configuration, you could see the data
with out the master password.

>In 90% of all cases we talk here about passwords that Mozilla later on
>sends over a non-secure, non-SSL connection, so every network sniffer
>would reveal them and even people not sitting in my local network would
>see them by logging all IP packages on a router in between.
>
>
That not mozilla's fault. It warns you *BEFORE* it send data over an
insecure connection, unless you tell it not to. If you are willing to
send important info that way that's your problem. Personaly, I don't.
SSL connections aren't hard to implement, if only for login use, so that
data is not sent in the clear. Tell the webmaster to fix the site.


-Thomas

Thomas Dodd

unread,
Dec 2, 2002, 2:43:49 PM12/2/02
to mozilla-...@mozilla.org

TGOS wrote:

>On 25 Nov 2002 16:12:49 GMT t...@cypress.com (Thomas Dodd) wrote in
>netscape.public.mozilla.security:
>
>


>>Build a debug version of mozilla,
>>
>>

>Building Mozilla at all, no matter what version, is Mission Impossible
>for me.
>
>
Why is that? I though it would build with cygwin + gcc.

>>If you really want to help, once you figure it out, write up a 1
>>or 2 page doc about the flow for other to use.
>>
>>

>That's what the developer should have done before even using the lib.
>
>
They just haven't gotten it done yet. And I imagine what they would
write is not at the level you want.
Welcom to OSS :)

>>systems. I run commercial X servers in M$, and
>>XFree86/cygwin is a fairly workable combination.
>>
>>
>

>The free version of Windows is horrible slow on a 1 GHz CPU, horrible to
>install, horrible to configure, instable and pretty much useless for non
>computer cracks. And why should I anyone have to pay to buy a XServer
>just to run a XServer app that he can get for free?
>
>
Thats your opinion. I had no truble getting it running, the installer
worked fine, and the performance was good. So you don't need to BUY and
Xserver. And I use it for non free apps. Expensive CAD tools running on
Solaris, displayed to PCs. While the comercial Xservers are a litle
faster, and easier to configure, XFree86 is fine.

>The XServer is a very slow graphics system (as you can see by various
>new additions to XFree86 to circumvent the standard XServer data flow),
>that has high needs to the network stack of a system and very high
>
>
That's only for remote display. For local machines it fine. Try getting
Win95, 98, ME, or MacOS to run an app on one machine and do IO on
another. Work has been done to reduce the demands, especially for modem
connections, and is working well, and getting better.

>hardware demands (memory for example). If I want to run the app on a
>
>
X11 has pretty low hardware requirements. I've used it on i486's with
32MB. I've also used it on 680x0 system running HP-UX and Solaris, with
8bit color (and 1bit) graphics. It's the newer toolkits like QT, GTK+
and GNOME, and apps like nautilus and mozilla, that are the resource hogs.

>server only system that only has terminal access, you are out of luck if
>it requires XServer and you can't install an XServer to this computer
>(because it can't handle it or because you have no permission to do so).
>
>
You don't need a server, just the libs. The tell the app to display on
another machine, one that does have an Xserver. If you have someplace to
write data files, you can add the Xlibs.

>The only graphical system that you can use safely is Java AWT, as Java
>is supported (with AWT) by some platforms that will never support
>XServer and it's really platform indepedent, however, it limits you to
>platforms with JVM and it limits you to using Java as language.
>
>
AWT has plenty of problems too. #1 is performance. Java is slow on every
system I've used, with every JVM I've used.

>>More to the subject, the mozilla developers, never intended the NSS code
>>to be used on non mozilla systems.
>>
>>

>Then they should never have used NSS right from the start to encrypt the
>web passwords. If they use it to have SSL support or to sign E-mails,
>okay, these are internal functionality where it doesn't make much sense
>to give external apps access to anything.
>
>
You can alway store your passwords unencrypted. It's your choice. You
have lot's of choices, but don't appear to be willing to accept the
trade offs associated with them. You also don't appear to be interested
in help make things better either.

>E.g. I have an USB key device that comes with a software that allows you
>to move IE user data to the USB key and back again (at the same computer
>or a different one). How much do you want to bet that this device will
>never support the same functionality with Mozilla?
>
>
That's up to the people that write the software for it. Depending on how
you access the device, it might be done by a programmer that has one.

>Do you think any picture format has any chance to survive if the format
>is not documented and if you ask for a doc, you are told "Why not use
>our lib that has been ported to different platforms?". Well, there are
>thousand reasons why not to use it. And like a picture file stores an
>image, a password file should store passwords, but that's not what it
>does in case of Mozilla. It's neither self-existing, nor is it easy to
>access without using the NSS lib.
>
>
I disagree with that. If the code for a library exits, I'd prefer to use
it. If it doesn't work, it's probably a better starting point that
starting from the ground up. The best I can tell the files do store the
user and password data. You just need to access it correctly.

>>>I thought it makes sense to store WEB passwords into a WEB BROWSER,
>>>after all that's the client that will need the passwords later on and
>>>that's the client that can pre-fill the passwords for me (something
>>>
>>>
>>
>>And mozilla does that.
>>
>>
>

>I know, that's why the web passwords MUST be in Mozilla's database so
>the functionality works, but Mozilla does not allow my app to write any
>such password there on its own. That means if I write a password
>managers and users have all their passwords there, but would like to
>have Mozilla pre-fill these... the user if fucked!


>
>
>>Do you think that PKCS #(5. 7, 11, and 12) support is
>>a bad thing?
>>
>>
>

>No, but there is a difference between having support for something or
>using it where it it's not necessary.
>
>There's nothing wrong with giving Mozilla a general interface, so people
>can plug-in their own security extensions, smartcard or USB encryption
>device hardware, whatever.
>
That's what you got. Using a standard interface for security modules.
Read the specs for PCKS#11 to figure out how to use it.

>E.g. Mozilla could have just offered an interface with functions like:
>
>initMasterPassword(password);
>storeWebPassword(url, name, value);
>value = loadWebPassword(url, name);
>
>
They uses existing, industry standards instead of a new one.

>And how these are then implemented in the library below can vary. But
>the default implementation should be as simple as possible and as well
>documentation as possible. And for me, the simplest way is to store all
>key pairs in XML format (Mozilla stores EVERYTHING ELSE in XML as well,
>history, cache information, skin data, overlay extensions, etc. so why
>not the passwords???) and encrypting it with the master password (that's
>secure enough unless the user chooses a poor master password, but that
>would then be his own fault).
>
>
Have you looked at the unencrypted password files?

>>That not mozilla's fault. It warns you *BEFORE* it send data over an
>>insecure connection, unless you tell it not to.
>>
>>
>

>Which will not help me at all, because if I refuse to send it, I won't
>be able to log in at all to the service!
>
>
>>Personaly, I don't.
>>
>>
>
>Then you can't use 90% of all online services.
>
>
Itr works for the sites I've wanted to use. What online services are you
trying to use that require login but don't use SSL?
I've seen a few that don't offer plain text, or <128bit encryption, but
none that offer no encryption.

-Thomas

Mitchell Stoltz

unread,
Dec 9, 2002, 3:03:04 PM12/9/02
to
TGOS wrote:

> I was trustful that people actually think about such things like "Does
> it make sense to offer third party apps easy access to the data without
> forcing them to use our libs". I didn't know that things like this are
> never considered right from the start.

Who says it wasn't considered? There are a lot of things we could have
done with Mozilla. We could have added a word processor, too, but we
chose not to. If you feel that Mozilla is severely lacking becasue we
chose not to provide an easy method for non-C-programmers to access a
particular C-level API, while you're entitled to your opinion, you are
probably in the minority.

The bottom line is, if you want help with your project, you are going
about it in exactly the wrong way. No one who works on Mozilla is under
any obligation to answer your questions. We make an effort to answer
questions when people are polite, but nobody pays us to do it. Calling
Mozilla engineers names and refusing to post in the correct newsgroup
are not good ways to receive assistance. A little courtesy goes a long way.
-Mitch Stoltz

michael lefevre

unread,
Dec 15, 2002, 8:22:58 PM12/15/02
to
In article <6mhpvukmrsn28mvea...@4ax.com>, TGOS wrote:
>
> On 24 Nov 2002 01:16:52 GMT ben.buck...@beonex.com (Ben Bucksch)
> wrote in netscape.public.mozilla.security:

>
>>>> And if *you* expect to be taken serious, then follow the charter of the
>>>> newsgroups you post to.
>>
>> http://www.mozilla.org/community.html
>
> Neither Netscape, nor the Mozilla community OWN these NGs. I'm (for
> example) posting to a local copy of this NG on my news provider, which
> is neither Mozilla or Netscape, nor in any way related to both.

true to an extent, but it's a netscape group. netscape could change a
setting, and partition the "real" copy of the group from the ones that
exist on various servers around the world...

> The charter of a NG is per definition the body of the newgroup control
> message and not anything written on some webpage

I doubt that there has ever been a proper control message for this group
- it was simply started on a private server.

> , because what is
> written on some webpage can change, charters can't change per
> definition.

there is no charter AFAIK.

> Have a little excursion on Usenet history, thank you very much.

I think it's you that needs to do that "Usenet" is a specific set of news
hierarchies - "netscape." is not one of them. this group doesn't
officially exist, it was just created on a private server, and then some
news admins decided to carry it... in terms of charters and control
messages, it has about the same status as the large number of funky alt.
groups clueless people have created which have not been agreed in
alt.config...

--
michael

0 new messages