Lack of interest XenForo Password Types (Add Key Files)

[ZionHD]

I've been wondering this for a while, why doesn't XenForo have any different type of password types?
One example would be key file(s).

It may raise the problem of DoS or of some kind for XenForo, but why not just make it an option/permissions that Administrators can enable/give.

I'm pretty sure most Administrators will most likely have a high-end dedicated server or Co-Location with their own material that would like to use this option. Because they most likely will have the server that may/may not be able to handle it (depending on the key file(s) size, which can be limited if it raises an issue).

So if by any chance XenForo can add key file(s) password authentication that'd be great.

 

[Mike]

I'm not sure what you're referring to with "key files". I presume you're talking about encryption keys, but passwords aren't encrypted; they're hashed. The amount of "stretching" done in the hash is configurable via config.php (harder to brute force vs time to check correctness).

 

[ZionHD]

I'm not sure what you're referring to with "key files". I presume you're talking about encryption keys, but passwords aren't encrypted; they're hashed. The amount of "stretching" done in the hash is configurable via config.php (harder to brute force vs time to check correctness).

I know the passwords aren't encrypted if it was then that would represent a huge security risk.
Basically, instead of using commonly used passwords something an attacker/hacker (what ever term sits right with you), why not use
a file something that will be hard to find, guess, or crack.

Yes, I know that BlowFish/bCrypt is a secure way of hashing passwords considering the time it takes to just crack a BlowFish/bCrypt hash.
Although, this does not stop people from using commonly used passwords which is what most attackers aim for.
So, most attackers wouldn't need to crack the blowfish/bcrypt hash, they'd just crack the easier hash which would be something like md5 or sha1. (If people use common passwords).

Yes, I know that you can just use a randomly generated password with a longer length, but you would still have to save the passwords some where though. Because I highly doubt anyone unless you have photographic memory then most likely you will be able to remember a randomly generated string.

 

[Mike]

I'm not sure what you're suggesting them. Are you suggesting client-side certificates? You can see some discussion here: http://security.stackexchange.com/questions/72704/using-client-side-certificates-for-authentication

If you're the kind of person who would actually consider using a client-side certificate, you might as well just use a password manager.

 

[ManagerJosh]

I might be wrong, and @Mike can correct me, but it's my understanding that the XenForo passwords requirements for storing passwords were "uniquely salted bcrypt hashed"

 

[Jeremy P]

Basically, instead of using commonly used passwords something an attacker/hacker (what ever term sits right with you), why not use
a file something that will be hard to find, guess, or crack.

Yes, I know that BlowFish/bCrypt is a secure way of hashing passwords considering the time it takes to just crack a BlowFish/bCrypt hash.
Although, this does not stop people from using commonly used passwords which is what most attackers aim for.
So, most attackers wouldn't need to crack the blowfish/bcrypt hash, they'd just crack the easier hash which would be something like md5 or sha1. (If people use common passwords).

Yes, I know that you can just use a randomly generated password with a longer length, but you would still have to save the passwords some where though. Because I highly doubt anyone unless you have photographic memory then most likely you will be able to remember a randomly generated string.

I'm not entirely against this suggestion, but if someone were going to use a commonly used password to begin with then I doubt they'd take the extra effort to generate and use a keyfile instead. And if you are willing to take that extra step, you could instead spend the effort setting up an encrypted password manager like KeePass with randomly generated passwords, which is already more practical since it works for nearly all existing websites.

 

[ZionHD]

I'm not entirely against this suggestion, but if someone were going to use a commonly used password to begin with then I doubt they'd take the extra effort to generate and use a keyfile instead. And if you are willing to take that extra step, you could instead spend the effort setting up an encrypted password manager like KeePass with randomly generated passwords, which is already more practical since it works for nearly all existing websites.

Well with passwords manager if you have staff on a site you can't say for sure that they will use randomly generated passwords or a password manager that generates random passwords if it is long distance communications.

Which is why I included this:

but why not just make it an option/permissions that Administrators can enable/give.

To make sure it is enforced on a specific group/user, or to allow a specific group/user to use the key file(s).