Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about programming within the scope defined in the help center.
Improve this question
i guess that algorithms used to crypt password becomes weaker year after year due to the new technologies (CPU more powerful, GPU...),
So; does this mean that a user registred in 2006 is less protected than who has registred in a 2012?
Then; how to update the password of that user of 2006? (for example Yahoo, if am registred since 2006, then my password takes less time to crack than the password i'll put in 2012, so how Yahoo will do to update my password to the new powerful system?)
In other words: how to migrate from a system to another (from MD5 to Bcrypt for example for the existing MD5-hashed passwords)
There are two actual problems:
CPU power increases, so brute force cracking increases
Older algorithms get less secure
The latter one is fixed by changing the way you normally hash and store passwords in your database. You can already do this every time a user logs in when their password is stored in the old format.
The first one requires an actual change of the password and you should 'force' users to update their password every so often and check (or at least indicate) password strength when they enter a new one.
Another way to counter the increased CPU power is to limit the number of password tries after a number of failed ones and thus prevent brute forcing of the password.
In general though I think proper management of password storage is lacking in most websites and systems.
If your hashing scheme involves just repeatedly hashing the current value (1000s of times), then you can always later increase the iteration count (just not decrease it).
You can use bcrypt as your iteration function so you get the benefits of both schemes.
Like this:
var hash = bcrypt(pw, salt);
for N iterations:
hash = bcrypt(hash, salt)
You can always "append" new iterations in the future.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
There is a password generator that generates passwords based on known rules (a minimum of 10 characters in length, at least 1 of each of uppercase, lowercase, and numeric characters).
No ability to see the source code for this generator. I am just able to generate passwords and automate this process.
How would you test if this generator provides unique passwords assuming each password meets rules specified?
Thanks,
Racoon.
It does not generate unique passwords - that much I can guarantee you.
If you run this password generator a hundred billion times, what are you expecting to be true of the output? Are you really expecting that every one of those hundred-billion passwords will be different?
If what you're instead trying to ask is whether the passwords will be reasonably unique, then you need to define what you mean by 'reasonably unique'.
It also depends on the nature of the rules you specify for generating these passwords. If you specify a maximum length for passwords, then you have by definition set an upper limit on how many unique passwords there even are. Even if you don't, the only way you're getting guaranteed-unique passwords is if said passwords are allowed to grow to lengths that will make them totally impractical to use.
I think my question was incorrect. Every password generator sooner or later provides a value that have been earlier. Better think of randomness than unuqueness.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
We will have multiple (eventually hundreds of) embedded servers going out in the field to client sites and coming back to our site. We need to be able to securely log in to any server from any of multiple clients (laptops, tablets, etc.) both here and out in the field.
I'd prefer SSH (or equivalent) but with hundreds of servers if a new client is introduced (e.g. a laptop dies and we replace it) it will simply be impractical to generate a new key pair and update all the servers individually (many of which will be offsite and temporarily inaccessible) with the new public key.
Other than generating a single key pair and copying the private key to each client (an obvious no-no), is there a way to securely accomplish this?
Thanks!
OpenSSH can be configured to accept certificates signed by a CA to authenticate both users and hosts.
Read the CERTIFICATES section from the ssh-keygen(1) manual page.
Generate a bunch of key pairs ahead of time (more than you'll need), and push all of the public keys to the servers. Keep the extra private keys in a safe or in some similarly secure location, and issue them to clients as needed.
This still doesn't leave you with any way to revoke keys, though, which may or may not be a problem.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Theoretical question here:
How do people feel about the restrictions that registration forms have for users' passwords? Meaning, is it wise to make a condition that the user must have a capital letter, a number and a special character? I recognize that those conditions usually would require users to make a more secure password, but would that be annoying to a majority of users (it annoys me that a website assumes I do not have the capacity to create a secure password)? Any opinions one way or the other?
Yes, pretty much. You should also make a JS script to check for the password strength while user is typing it in. Just to inform the user and not let him submit it before a certain strength level is reached.
I would recommend some sort of password requirement to ensure basic security. However, making the requirements too stringent will hurt usability and, if they're encountering a rule they're not familiar with, could force them to create a new password which they could later forget. My advice would be to look over the requirements for popular websites such as Google, Facebook, etc. to get an idea of common requirements. If they've already encountered whatever requirements your website uses, they're less likely to get upset and can reuse memorized passwords.
Note: I know password reuse is a bad idea, but the majority of internet users don't want to memorize a new password for each site they create an account for, and it's therefore best from a usability perspective to allow them to do so.
You should also be careful about what characters you are going to allow in the password. Some secure input controls only allow ascii.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm looking at the various bcrypt implementations across several languages and noticing the character limitation across most - specifically, the 72 character maximum that node-bcrypt, php's bcrypt, and py-bcrypt all exhibit.
What are the advantages and disadvantages if an application were to run user input through, say, a SHA-256 or SHA-512 checksum beforehand to enable longer inputs for bcrypt?
The CLI application found here is limited to 8-56 "characters" inclusive (it's C, so a character can be anything I suppose). Heaven knows why you would create limits for something that you feed into a password based key derivation function afterwards (which almost certainly will take unlimited input).
An additional secure hash with sufficient strength and output size will not do anything to degrade security.
Encode the result to hexadecimals before feeding it to a bcrypt library, which is almost certainly expecting a String (don't get struck by the "odd" 00h byte). You might as well use SHA-256, I don't think a few bits more or less will make a difference if you feed it into bcrypt afterwards. Otherwise you may be forced to use base64.
Finally, try not to get into this situation, performing non-standard cryptography is almost certainly a bad thing.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
My friend easily finding my password,using firebug..i.e when i am in login page ,my friend using inspect element to find the password element and he changes the type="password" to type="text",now its shows the password...how to avoid this????
Obviously your friend can only do this if he can get to your PC while it's got the page loaded and mess around in Firebug. And then, since all he's done is make the password characters visible, to find out what your password is he has to stand over your shoulder to watch you type it.
This sounds more like a prank than a serious hack attempt. There are much worse ways to get hacked than that, especially if someone has direct access to your PC while you're logged in.
If you're writing a web site, and you're really worried about this sort of thing, there are steps you can take to prevent it.
For example, instead of asking the user to enter their whole password, you could give them a set of text boxes and ask them to enter just a few random characters from their password -- eg you could ask them to enter the first, fourth and eighth characters. This means that even if someone was watching what they typed, they'd only find out part of the password, which would be useless to them next time when the site asked for a different set of characters.
There are, of course, flaws in this scheme too, and it's a lot more of a hassle for the user, but it is considered more secure.
But typically it's only banking sites and the like that go to this sort of length to protect passwords. Most normal sites don't need this sort of level of security.
The best solution is to .. not store your passwords in your browser.