Security

What defaults should random password generators use?

Chad Perrin is building his own password-generating tool and is pondering what kind of defaults regarding length and character selection to include. What would your preferences be?

How would you prefer a random password generator to work?


There is something to dislike about every password management application I have found, at least for my purposes. I have made do until now, but I finally decided to write my own password management tool.

One of the things I want to be able to do with my password manager is generate random passwords on the fly, as needed. Of course, the preference would be to create incredibly long, complex passwords, if I am going to handle them via a password manager rather than trying to memorize them all, but different uses for passwords will run into different password policies. All too often, some Web site will restrict the length of the password or the selection of characters I can use quite a bit more than I would like.

As a result, I need the random password generator component to be tweakable as well. That is the easy part. On the other hand, a tool like that might be useful on its own as well. It also might be useful to more people than just me. As a result, I probably will make the password generator component a separate tool and make it available as an open source app. Actually, I plan to do so with the entire password management toolset. It will be simple, and not very special, but it will provide an at least slightly different approach to password management than anything else I have seen, which some might find useful.

Making something with configurable behavior available to the public raises the question of defaults. There are two defaults in particular in which I am interested in this case, at this time. One is generated password length, and the other is the range of special characters to use.

Keep in mind that I am probably going to make the password generator component a combination library and command line tool, so that if it is used separately as a lone tool it will take command line arguments (for instance, -l 15 to specify a fifteen character password length).

Default length

I am considering options for how best to randomize lengths. For that purpose, I think I will provide options for both an explicit password length and a maximum password length. If a maximum is selected, a variable length within a range of lengths close to the specified maximum will be selected.

The question in this case has two parts:

  1. Should the default length be a variable length or an explicit length?
  2. Should the default length be relatively low or relatively high?

I am leaning toward an explicit length of either 10 or 20 characters. Twenty would be far too long for a lot of Websites, which suggests that perhaps ten should be the default instead. On the other hand, twenty would encourage stronger passwords, and when needed, users could reduce the password length via the option to set lengths. Of course, if you have other ideas with good reasons, those would be welcome as well.

Default character selection

On one hand, allowing pretty much every ASCII character would encourage better security in much the same way as using a longer default password length. On the other hand, using only case-sensitive letters and numbers would work almost everywhere. I am personally inclined to allow all characters the program can handle by default, but I am not necessarily wedded to that choice.

Seeking input

What do you think? What do you think would be best to encourage good security practices for end users who may not necessarily be inclined to use defaults if they can avoid it, without scaring them off by making the tool too much work to use? What would you prefer for your own use? I look forward to suggestions and discussion in comments. I do not guarantee to do what you ask, but I do promise to consider it.

Worried about security issues? Who isn't? Delivered each Tuesday, TechRepublic's IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

56 comments
fw32
fw32

When you register for access to a site such as a bank, or email service, you are a valuable commodity for ad counting visit credit or some other accounting purpose and to avoid responsibility for password ineffectiveness avoiding the overhead of managing passwords, at a minimum. Mandatory difficult to remember passwords are an anathema to easy joining so where membership numbers equals revenue there is no good answer if the member chooses the password. What is truly needed is a secure unhackable lockbox on the individual computer to house a website detector which will seamlessly output the correct password for the visited site. Once that password was accepted, various additional mutual recognition tests such as further passwords, whois data, preset time of day, etc, could be traversed to validate the connection. The user need not ever have knowledge of nor access to the password making it possible for long, complex, access rituals beyond human manual ability. However securely an individual can be related to the computer being used, such an automated relatively secure system can be constructed. Fingerprint, retinal scan or DNA check would probably be required here for the higher end to establish computer-user rights .

allouttr
allouttr

Interesting subject but I have another related question. Suppose you do create a nice random password generator and you store the passwords by application in a secured fiele on you computer. How safe is it to copy a password from this file and past use it to paste into the password block of your on-line bank account logon screen?

DontKnowItAll
DontKnowItAll

Why not just use LastPass or some other similar password manager / generator? LastPass already has the features, is free, and works great. A savvy user can set appropriate parameters for himself, and the average user wouldn't know what to do anyway unless she takes the time to self-educate on what is appropriate and adequate.

chrisreich
chrisreich

The random password generator I use always gives me 64 characters, but I select a subset of the 64 by highlighting and copy/pasting as many characters as I need or want based on the use.

apotheon
apotheon

I just want to thank everybody who offered suggestions. Please feel free to continue to offer suggestions -- I'm not saying I'm done listening. I just want to make sure you all know it is appreciated, even if I have not responded to everyone individually.

NightLife6
NightLife6

Comply with the basic guidance contained within: http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final-errata.pdf See: Pg F-58 for specifics... - Control Enhancements: (1) The information system, for password-based authentication: (a) Enforces minimum password complexity of [Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type]; (b) Enforces at least a [Assignment: organization-defined number of changed characters] when new passwords are created; (c) Encrypts passwords in storage and in transmission; (d) Enforces password minimum and maximum lifetime restrictions of [Assignment: organizationdefined numbers for lifetime minimum, lifetime maximum]; and (e) Prohibits password reuse for [Assignment: organization-defined number] generations.

Harry.Hiles
Harry.Hiles

There are plenty of password generators/managers available to use as models for your tool. I use LastPass (https://lastpass.com), which is browser based and both generates and "remembers" passwords in an encrypted file. The generator has options for length (1-100), A-Z, a-z, 0-9, and a fixed set of 7 special characters: #^!%@&*. Other options include minimum digit count, avoid ambiguous characters, and require every character type. There's also a strength meter. Although a random password generator is helpful, it must be coupled with a store/recall function to be effective. I have unique complex passwords for every one of my secured sites, and the only password I need to remember is the one I use to log in to LastPass.

johnmckay
johnmckay

Surely setting any defaults is one step closer to cracking it? I prefer a simple minimum length and depending on the system you could add a couple of upper/numeric/key requirements. It has to be flexible, random length or foplk just write them down; totally defeating the whole point. Too little is bad practice; too much is even worse!

Aaron.Kee
Aaron.Kee

A good program I've been using is PC Tools Password Utilities. This gives you the option to set the length of the password, and your desired criteria specifications: letters, numbers, mixed case, punctuation, and even no similar characters. Another nice feature is that it allows you to download a local copy of the tool or generate it online from their secure site (https://secure.pctools.com/guides/password).

Shepps
Shepps

Interesting article, and yeah it is quite an issue, even for tech-savvy people. I tend to use the same password pattern (as opposed to password) for websites, but use generators for important sites like banks. IMHO the best thing you could do is look how tools like Roboform consider Password Generation (as an aside I think Roboform is the most useful tool on my PC and has been for years!). Basically a Generate button just sits on my browser the whole time (in the roboform taskbar). If I mouse over the button a little popup appears ready to create my next random password. There are variables set to defaults: number of characters, defaulted to 8, which is a bit weak. Then there are checkboxes for A-Z, a-z, and 0-9. These default to being selected. Then a user defined list of characters (!@#$%^&*) defaulted as not-selected. It allows you to set the minimal number of digits, defaulted to 1. It then has two other settings which I never use: 'Exclude similar characters' and 'Hexadecimal'. Finally at the bottom it tells me the bit strength of the chosen password. I think the real great thing (for you) is that you can set defaults. Users are fairly lazy people (me included) and I tend to stick with defaults. I think the default length should be about 16-20 characters (I remember reading somewhere that to beat rainbow tables you need that sort of length). So set the defaults to strict levels but allow the user to make the bit strength lower (to a minimum that you consider OK) Another benefit with Roboform, the password that is generated stays there until you either close the browser or another setting-invoked event happens - I think you can set it to last for x minutes before it isn't shown any more. Why is this useful? Well, often you have to fill in the same password twice on the webpage and this allows you to drag and drop the password, retaining it until you have successfully entered it. Then you are free to clear it, or just allow it to 'decay' normally (time-invoked or until browser is shut). That is a nice feature! Good luck! :)

RayG314
RayG314

Chad, An idea: can you have the user enter one or two dates/facts, then your system could generate passwords based on those personal items. People could see the relationship of the password to their data, and remember their password. I've encountered a wide variety of password requirements, and minimum specs, such as yes or no to spaces or special characters, so I'd suggest your system be able to accommodate them. And would an expiration date be important? And to avoid widespread reuse of a single password, it would be nice if your system included or integrated with something of a password keeper/locker.

ddreibelbies
ddreibelbies

Would it be possible for your code to use the default explicit length of 20 (characters including ASCII special characters); but provide a message for sites where this cannot be used prompting shorter length or removal of special characters? I know that is a lot of conditionalizing (sorry...). However, it is close to the best of both worlds. Thanks.

jensen
jensen

I prefer 2-word passwords when a space is allowed. I also liked the password program when I was at DEC (RIP): it gave you a choice of several, each one pronounceable, and the phonetic pronunciation (these days maybe it would have offered a audio pronunciation).

Justus
Justus

Different sites have different requirements. The defaults should be settable per hostname or site. There should be options for what characters/letter/case, what symbols, numbers, how many of any one kind at a minimum (e.g. at least two digits and two upper case letters). Of course length should be settable from six (with a warning that six is not secure) to some large number for things like WPA2 keys etc.

apotheon
apotheon

I'm open to suggestions for default behavior other than for password length and allowed characters, too.

apotheon
apotheon

That depends on a number of factors. One such factor is how your system's "clipboard" works. Another is the browser. A third is the site's vulnerability to cross-site scripting. Other factors that have not occurred to me in the time it took me to write this may also apply. It certainly should not be any less secure than typing the password from memory, however. After all, the major difference in opportunities for exploit is that with the password manager copy/paste approach you rely on the security of the clipboard application, and with typing from memory you rely on the security of the act of typing in the password (which assumes nobody is shoulder-surfing you ether directly or through some kind of monitoring such as security cameras in the vicinity, and that there are no keyloggers, and perhaps something else I don't remember right now).

Harry.Hiles
Harry.Hiles

But these are good guidelines for user authentication systems that establish and enforce password policies. A password generator would need to consider and address requirements of item 1a, but the other items are strictly for policy enforcement.

martian
martian

The one I use and have become comfortable using is Password Corral by Cygnus Productions. Unfortunately, afaik it definitely appears to be closed source, which is the only negative I can find with it. It does sport a generator and has fairly good flexibility in configuration, but has to be set before the actual generation. I'm guessing I will be using Chad's before long... Keep up the good work. Ttyl, Gary

seanferd
seanferd

"...the professionals..."? The author is a professional. But I wouldn't necessarily want to see him (nor would I suspect that he would) copy some professionals in the way they generate pseudorandom passwords. If you meant "copy" in terms of interface design, it seems that you aren't alone in missing the idea that this will not be integrated into some other app or a web browser.

Neon Samurai
Neon Samurai

Passwords should be disposable; remembered while valid and easily forgotten or replaced at any time. Basing the password generation off a short list of personal information may result in a computer aided version of "bob1, bob2, bob3" series of passwords. Even with a more complex generation function, passwords may remain guessable due do to the creation formula. A two or three fields for "I lost my password" questions and randomly generated answers would be handy though. Those questions should not be answered honestly when signing up with the website to keeping unrelated answers to them written down blocks the Sarah Palin attack vector.

flaarnsturgen
flaarnsturgen

Back in olden times, MCI Mail had a good algorithm for coming up with passwords that were both memorable and random -- just alternate vowels and consonents. Using this approach to form multipart passwords would yield things like SEVARUSA RUMABIXE. For cases where you really do need to keep the password in your head (like the password for your password management software), this is a great feature to have.

apotheon
apotheon

The password manager itself isn't intended to integrate directly with a browser. It's intended to be a general-purpose tool that does some neat tricks with a "clipboard" to easily drop the right passwords into the right places without involving more complex pieces of software than necessary. A means of matching a domain to get the right password is part of the plan, though. There should be options for what characters/letter/case, what symbols, numbers, how many of any one kind at a minimum (e.g. at least two digits and two upper case letters). I'm a little concerned with the complexity of specifying such defaults on a per-site basis, though. As stated in the article, too much difficulty might chase of some users, and I'd like to keep things simple for the most part. Fine-grained control of password generation is definitely something I'd like to provide, though. Of course length should be settable from six (with a warning that six is not secure) to some large number for things like WPA2 keys etc. Frighteningly, there are cases where lengths might get as low as four, as in the case of certain banks that require a PIN for account access. While the way I handle that is to use a different bank, that doesn't mean that people who do use such a bank don't need a password manager, so I intend to make length setting essentially arbitrary.

dina04
dina04

How can anyone trust that the program is really generating random passwords and not just giving you one from...say 1,000 it has stored? Even with amount your password can be easily determined. Why should you trust anyone with coming up with a password for you? You should somehow be physically involved and the software facilitating your effort.

shardeth-15902278
shardeth-15902278

Assuming we get to the point where everyone is actually using generated passwords, A common fixed length would be the next likely weakness to exploit, to reduce brute force time. Maybe a configurable upper and lower bound, with defaults at 16 and 64? Yes, this means many(/most) sites would be exceptions, but I'd prefer to treat sites with poor password policy as exceptions, rather then relax my tools to accommodate their poor design. For convenience, I suppose one could add a small "crappy site" button, which would utilize an alternate set of defaults, based on common "weak site" limitations. That way, accommodating a bad site would be a matter of sighing, shaking your head in disgust, and clicking a button to reduce the generated password to 8-12 chars, limited to alphanumerics.

dan
dan

Somebody needs to create a random generator with several options, character sets, PW lengths and so forth so systems with hardwired restriction policies can still utilize the program. And finally a way to ensure employees are following policy.

dina04
dina04

Have the passwords generated by random movements of the mouse. Let users designate length and characters included AND to generate a LIST with as many passwords as one wants. Say someone may designate 1,000. He then opens the list and cuts and pastes the password he knows. But anyone else who got the list would still not know which password is correct. Better yet just remove all the spaces and create a large random text file.

AlexNagy
AlexNagy

Default: 12 characters, variable from six (max I've seen on some sites) to 32 (I've encountered a site or two that don't seem to have any restrictions on length) Default: caps-sensitive characters with options to include/not include the full range of ASCII characters option: use random seed generator to help randomize the passwords?

santeewelding
santeewelding

Sans the obtuse for which you grow near-famous for.

Shepps
Shepps

I didn't mean any offense by that. I just meant that it can help to look at other solutions when deciding what you want to implement yourself (when creating tasks in Excel I often have a quick look at what fields Outlook has by default but then tailor some extra ones of my own) I can't think of needing anything else that Roboform supplies, so I would design it around the few features it has, but that doesn't mean there aren't others who think other features are needed. I quite liked the idea of having profiles of a collection of settings which a few people have suggested. I wasn't referring to the GUI, but ultimately, no matter how you implement it, having some sort of interface from that tool to entry into an HTML form becomes paramount. FYI Roboform lives outside the browser too, but hooks into all known browsers as well as all Windows passwords popups (i.e. when accessing network drives that require authentication). All in all it is the best software I have ever used... noone else uses it?

Rick_from_BC
Rick_from_BC

Many of the sites will have a set of restrictions for acceptable passwords, along the line of: - minimum 6 characters - maximum 14 characters - upper and lower case letters - digits from 0-9 - may/may not use *$@?/{[()]} - et cetera Would it be possible to set these as selectable conditions per site? Users would check off the appropriate conditions as laid out by by the site. Many of the sites I visit have a pretty standard format for these restrictions, so users should not have a problem ticking the right boxes, The problem sites would be those that have arbitrary rules (at least 2 numbers together, Cyrillic alphabet only - that sort of thing) but thee are fortunately rare. Good luck with this project. PS In Canada, I can set up my bank card with chip to a 5-character password, but it is recommended that I restrict it to 4 digits, "to ensure I may use my card in foreign (American and European) sites."

AlexNagy
AlexNagy

I was thinking that it would be output to some sort of stdout (console, gui popup, etc.) so one could copy/paste on their own. That way if the minimum of six is too large, just copy all but two characters and bam.

apotheon
apotheon

How can anyone trust that the program is really generating random passwords and not just giving you one from...say 1,000 it has stored? This is why you should only trust such software as far as it trusts you. That means being able to see the source code to verify for yourself how it works, and having the opportunity to actually use software produced by the source code that you can see so you can verify that the source you see is the source used to produce the application you use. In the case of a program that is written in an interpreted language such as Ruby, you basically get to see the source code no matter what, because the interpreter runs the program from the source file. In the case of a compiled language such as C, you have to have the opportunity to compile the executable binary from source yourself if you want to. You don't have to actually read the source yourself to be able to verify this, as long as enough other people without any ties to the creator of the software have it that some of them are sure to look through the source, because the key to being able to have a reasonable expectation that the creator isn't trying to pull one over on you is that the creator is willing to share with people who might catch him/her/them in the act, and will thus not do anything stupid when writing the code. This is a key factor in how to choose the right licensing model for security software, as well as of the concept of security through visibility. This is why, once the program is in a form worth sharing, it will be shared as open source software -- under a copyfree license, the OWL.

apotheon
apotheon

That's an interesting idea. I'll have to look into the idea of a secondary default for policies that enforce weak password policies. Thanks for the inspiration.

apotheon
apotheon

Of course, this particular tool is intended to be a way to make it easier to use strong passwords -- and not necessarily a way to "enforce" password policy. I think that part of the problem of trying to enforce policy people don't like is that they'll always look for a way to do things in a way that makes things "easier" for them. Those who do not really understand the importance of security and the implications of their actions will more often than not come up with a way to undermine security in service of their convenience. The two things that work best for getting people to use passwords security are, I think, education and the usability (i.e. convenience) of the procedures they use to manage their passwords. This tool is an attempt to address the second problem, primarily for me (because while my current procedure works well it's not as convenient as I'd like), and incidentally for other people. Thanks for the encouragement.

MarkGyver
MarkGyver

I definitely would want the program to incorporate high-quality sources of randomness/entropy. /dev/random (or the non-unix equivalent) would be a good start, but I'm a bit too paranoid for just that. Here's a possible example/how-to of extreme paranoia about password randomness: * Use an online password generator over HTTPS * XOR that with something generated by your computer * XOR that with something generated by your graphing calculator/mobile device * Generate about 2-10 times as many characters as you're going to use in your password * Roll dice to determine which of the characters to use and in which order Is there a way to simulate this level of mixed randomness in a single program? As for character choices and length, it's pretty easy to just skip any parts of the password that don't work when typing it in somewhere. Even if the place the password's being used for has no such limits, I think it's still more secure for the user to contribute to the entropy. Overall, this sounds like it's going to be a great program!

RedDawg
RedDawg

I personally PREFER 15 - 20 character complex (upper and lower case with numbers and characters)passwords. When assigning passwords unfortunately MOST USERS WILL IMMEDIATELY CHANGE anything over about 10-12 characters, in many cases "anything over 8 characters iss too hard to remember". A good random PW generator is a great tool/utility for an admin, but enforcement through security / system policy will still be required.

apotheon
apotheon

I've already started writing the code for the random password generator, and an option to feed a seed to the program is already part of its capabilities. I'm still kicking around options for how exactly it seeds should be fed to it (sockets, et cetera).

fw32
fw32

is in the eye of the beholder.

gshollingsworth
gshollingsworth

I use it. It is a Windows app which does not quite work in wine. I haven't tested wine compatibility with newer releases of either wine or Roboform though. Free use is limited to 10 logins remembered. I have a license for the "togo" USBflash version which has the added benefit of not requiring installation or admin rights. There is a 30-day tryout period for all the features then the 10 login limit kicks in. Now for it's password generator. I think it is a very good implementation. It's GUI options can be translated to a CLI easily. It allows from 1 to 511 characters and starts at 8 at install but has no default instead remembering the last length. It has seperated character sets to upper A-Z, lower a-z, number 0-9, and user defined list of specials each with a checkbox. A shortcoming I have found is the specials list is remember from the last session. I simply delete disallowed for each session and never repopulate. So now I have a short list of specials allowed from all previous sessions. Only 8 out of up to 33 possible, pitiful. I has the ability to specify a minimum number of digits but not other sets. As mentioned excluding similar chars is an option off at install. The Hex option is mutually exclusive with the char sets since they all reference the Qwerty/ASCII US macro set of characters. A very important feature it has is a bit strength feedback. I think there may be an error in it's algorithm but it is close enough to be meaningful. The factors of length and number of usable characters minus any disallow rules determines the maximum possible strength of a password. You should encourage the maximum of all positive factors but allow reduction as an option. How crackable a password may be depends on the weakest link of the implementation of the password storage and handling. For example rainbow tables have been generated for Windows LM/NTLM hashed passwords. They were originally only 7 character, then doubled to 14 by storing two 7 char hashes. Due to the nature of the hash the two 7 chars are far easier to brute force than a single 14 char hash. NTLMv2 uses a stronger hash but the default implementation will also store the weaker hashes. It can be turned off or you can use passwords of 15 or more characters which cannot be stored in the weaker hash. So there is no hard and fast rule for password length. If a website is using Apache and MySQL and Fedora, then it is unlikely the passwords are handled or stored using MS LM/NTLM/NTLMv2 methods. But they may have their weaknesses as well. Most quoted lenght / strength calculations and estimated time to crack use LM hashes and whatever characters per second l0phtcrack can generate on the best available processor environment. So the time to crack will continue to fall and the strength must continue to rise. You also need to consider different hardware interfaces such a mobile phones, number only keypads, WPA2 keys, and various different uses of passwords/keys/passphrases.

apotheon
apotheon

Many of the sites will have a set of restrictions for acceptable passwords, along the line of: The kind of configurable behavior I have in mind should easily cover all of that. I do not think selectable conditions per site as a persistent configuration should be necessary, but they should certainly be configurable per use of the tool when generating a new password. After all, one typically only needs to create a new password for a given site once. If you know of a compelling enough use case for a persistent per site configuration option, though, I'd love to hear about it. users should not have a problem ticking the right boxes "Ticking the right boxes" may or may not be particularly meaningful in this case. I'm still considering options for the interface of the total password management toolset. As much as possible, I would like to minimize the need to interact with it the way one does with most applications, and simplify its use to the point where a couple of keyboard shortcuts will be all that is needed in many (most?) cases. Ideally, it should not even require one to see any sign of the app at all except for a password entry field, though of course that ideal is probably outside the realm of reasonability. As for the password generator itself, its interface when used as a discrete tool of its own will initially be limited to a relatively simple command line utility, so there won't be an actual GUI attached to it (at least at first). I really rather doubt it would be of enough use to most typical end users to bother skinning the thing up a nice flashy GUI when it's used separately from the entire password manager toolset. The problem sites would be those that have arbitrary rules (at least 2 numbers together, Cyrillic alphabet only - that sort of thing) but thee are fortunately rare. Some of that will be incredibly easy for me to handle -- and, in fact, the tool might be able to handle some Unicode by the time I'm done (I'm not sure yet). I'm not too worried about supporting internationalization at this point, though. I'm not sure what I'd do about crazy password policies like Nelnet's. I may provide a regular expression input for "power users" that want to deal with that. Otherwise, I think more typical end users will have to just specify as much of the ruleset for something like that as possible using the standard configuration options and generate new passwords until one of them works. Good luck with this project. Thanks!

apotheon
apotheon

It'd probably be configurable, but the clipboard capability for the complete password manager toolset is something I feel will be pretty necessary as an option for maximum usability.

Neon Samurai
Neon Samurai

Sure, a developer may be able to get two or three other's involved for a conspiracy. They may even represent themselves under multiple names on the project website. It's possible though still easily discovered. First, we're talking FOSS so the code is available and pretending to be twenty different aliases in the forums doesn't stop some random unrelated developer from glancing over the code. Maybe it's because they want to use the program, maybe they are simply looking at the string generator library for use in there own work. either way, the jig is up for the git that tried to release a backdoor'd FOSS application. Second issue; get it into the distributions. Packages don't get included into ubuntu, Mandriva, Debian or other distributions without vetting. In the case of Debian, there are several layers of peer review from "can this be included in your distro", through testing and finally into the current distribution version. Since new packages are not added to the current version; you actually have to get included into the unstable branch then earn your way into the testing (next major version under development). Most users will stick within the distribution's repositories and this is one of the reasons for that habit. Now, perhaps you setup a site on your own with "packaged for" in your download area listing several different distributions. There is a trust issue already by way of "why isn't this coming through my repositories instead of a third party?" You also have a number of folk who watch network traffic closely so your hosed when your little back door starts sending you password lists or opening ports for you to connect in through. Nothing is fool proof but there's a much bigger chance of discovery among FOSS than among closed source with it's limited developer teams and blackbox design. Personally, the very few packages I install from outside of Debian's repositories come from reputable third parties. Maybe Nvidia or VMware has snuck something in there but I'm not thinking that's the case.

dina04
dina04

And how can you be reasonably sure they aren't in cohoots with each other? Or still--Just one person can create "many" experts under different names making it appear that many have examined the code and gave it their blessing. If the rewards can, OR MAY, justify the time spent doing this...it will be done. Such new software may have to endure the test of time to be accepted and trusted.

apotheon
apotheon

But you still have to trust the people who can (hopefully) know how to read and determine the code. No, not really. You just have to have enough of them to be reasonably sure they aren't in league with each other.

dina04
dina04

Open source is mandatory. But you still have to trust the people who can (hopefully) know how to read and determine the code. I almost would like to see some sort of "spinner" where you can start and stop whenever while watching the numbers and charactres change before your eyes. Speed it up, slow it down, set the # of characters...

Neon Samurai
Neon Samurai

The protocol is holding up at least but true, who knows what the developers have in the source code. Offhand, how did they blacklist Skype installs? Our problem has been that it installs without admin privaledges. Our Group Policy version can only block install by specific installer program so to maintain a blacklist, we'd have to hire on a geek just to sit there with all potential user apps, confirm if they install, identify the installer and add it in; far to reactive to be of great use.

Shepps
Shepps

well said on the trust issue. In fact, in the company I worked for for over 10 years, they absolutely blacklisted any installation of Skype on a company computer for that very reason: Skype were/are unwilling to show the source code to the public, so you can never be sure someone doesn't somewhere have a backdoor into your conversation

apotheon
apotheon

I'll look into the possibilities for what kind of "Do I really want to do this?" prompts I might use to label that functionality. "pwn me" is a great candidate.

Ralph Wells
Ralph Wells

Instead of 'crappy site', how about 'Pwn me'?

Neon Samurai
Neon Samurai

Generating a random string then XOR'ing it a few times with different values should be easy enough. Dice can become mythical possessions for some serious gamers though; the debate rages on between the randomness of physical dice versus "dice roller" programs. But, the general principal of selecting random characters from the final random string should be easy enough if machine randomness is enough. Interesting idea to run it through so many jumbles though.

AlexNagy
AlexNagy

It sounded as if this was aimed at website passwords only. In that case, definitely allow up to at least 32 characters. An older (and not used anymore) password of mine for Windows was at or over that amount (spaces, special characters and the like)

apotheon
apotheon

It's aimed at passwords in the general case, which will almost certainly be Website passwords primarily.

AlexNagy
AlexNagy

but this utility seems to be aimed at website passwords. Between my MS XP account and FreeBSD account, my password is no shorter than 18 characters (and probably up past 32). For Internet usage, I do tend to stick to about 12 characters though because unless it's for a bank login or something similar, I do try to make it longer.