GoogleCodeExporter
commented
9 years ago I have to apologize for taking so long to respond to your request, Jon. I
haven't been ignoring it, I promise. I've been busy trying to focus on Cryptnos
for Android and bringing it up to parity with the latest version of Cryptnos
for Windows, as well as dealing with a lot of external factors, such as family
obligations, my day job, and the comic strip. Unfortunately, I've also been
struggling with how to respond to your request, primarily because it is in
direct opposition to some of the design decisions I made early on with the
application.
I think what we have here is a question of semantics: You seem to be
interpreting "lock parameters" to mean "add many sites to the database with the
same set of optional parameters" while I intended that to mean "lock all
parameters to prevent them from being accidentally changed". Perhaps "read
only" may have been a better term, but I think "lock parameters" is still
appropriate. Let me explain how the "lock parameters" option came about.
The default operation of the Generate button is to first generate the password
from the specified inputs then save the parameters for generating the password
into the platform's persistent storage (for Window's, that's the Windows
registry). Unfortunately, I quickly found that it was far too easy to "fat
finger" something and accidentally save an alternate copy of the same set of
parameters to the database, just with a slightly different site token or name.
This had the potential to clutter up the database with lots of unintended data.
It was also very easy to accidentally modify one of the other parameters, which
could "break" the password the next time it was generated.
I analyzed my own usage patterns and realized that while I might generate
passwords dozens of times per day, I only created new sets of parameters on
very rare occasions, such as when I created a new login on a new website. I
personally have around 60 sites in my Cryptnos database, but I may generate and
use those passwords thousands of times before I need to add a new one.
Thus, it made sense to provide a way to protect the database from accidental
modification. I didn't want to break the default functionality listed above as
it's very convenient when you first populate the database. That said, if I
added a "read only" mode that let the user generate a password for regular use
but which did not write to the database, that would solve the problem. Cryptnos
for Android solves this by taking the user down a completely different menu
path, ending in a form that allows the user to see the parameters but not
change them. Cryptnos for Windows has never had that sort of menu structure, so
an alternate way of implementing a "read only" mode was necessary. Thus the
"Lock Parameters" checkbox was born.
Based on the feedback I've received from others, the usage pattern mentioned
above--add rarely, regenerate often--seems to be the standard use case for most
users, and that's what was originally intended. Cryptnos was meant for
individual users managing their personal logins, and most people only add new
sites to the database when they create a login for a new site or application.
It is certainly easy under the existing system to add a bunch of sites with the
same optional parameters: Start by ensuring that "Daily Use" mode is turned off
and that "Lock Parameters" is unchecked. Select the optional parameters you
want, enter the first site's name into the "Site Name" box, type in your master
password into the "Passphrase" box, and click "Generate" (or hit Enter). The
first password will be generated and its parameters will be inserted into the
database. To create additional sites with the same parameters, just change the
site name and hit "Generate" again. Each time you hit "Generate" with "Lock
Parameters" unchecked, the parameters will be saved to the database. If the
site name already exists the existing parameters associated with it will be
overwritten; if the site does not exist, it will be added. Once you've added
all the sites you need to add, you can check "Lock Parameters" put everything
in "read only" mode. After that, hitting "Generate" will generate the site
password but will not update the database.
Now, beyond this, I'm not sure what you're asking for. I tried to come up with
a few possible ideas, but I could only come up with two:
1) I know you mentioned in your initial e-mail that you were planning to
suggest that your administrative staff use Cryptnos for password management.
This made me think that one thing you might have been looking for was a way to
enforce some sort of organization-wide policy to force users to use certain
parameter options, such as forcing minimum iteration counts or limiting the
types of cryptographic hashes allowed. This might be possible, but I'm
extremely reluctant to implement it for security reasons. Such a system could
be easily abused as an attack against users who never planned to use such a
feature. For example, I could have Cryptnos look in the
HKEY_LOCAL_MACHINE\SOFTWARE registry hive for system-wide settings which could
be set by some form of admin policy script. Standard users who do not have
administrative rights should not be able to change these settings without
elevating their privileges. However, malicious scripts that gain admin rights
could just as easily set such registry keys to restrict access to parameters
for non-enterprise users, artificially weakening their passwords or even acting
as a "denial of service" attack, preventing Cryptnos from functioning (if, say,
a list of permitted hashes was returned as an empty list).
2) The other interpretation I had of your request was as a means of using
Cryptnos to generate passwords en masse. The best scenario I could think of to
describe this might be for a help desk processing password resets, where the
help desk technician might generate a pseudo-random one-time password for a
user that has forgotten their existing password. If that's what you're
considering Cryptnos for, I would suggest you look for a different tool. As
stated above, Cryptnos was always intended to be used by individual users
managing their own passwords, much in the vein of competing products like
LastPass or SuperGenPass. If you need random passwords generated in bulk, using
something like OpenSSL would work much, much better. Something like "openssl
rand -base64 12" would give you a 12-character pseudo-random one-time password
much like Cryptnos without the overhead of cluttering the registry with every
password generated.
If neither of these scenarios are what you're thinking of, I'm afraid I'll have
to ask for some clarification. I'm reluctant to change the existing
functionality given the reasoning listed above, especially if it breaks the
expectations other users have come to rely on.Original comment by jeff.darlington@gmail.com on 7 Dec 2011 at 3:02
Original issue reported on code.google.com by
jcouc...@gmail.comon 28 Oct 2011 at 7:33