Tag Info

New answers tagged

2

The usual computations on password entropy take place in the context of a dictionary attack, especially an offline dictionary attack, where the attacker can try passwords at will without locking anything. When there is an auto-locking tamper-resistant hardware, the context changes. Conceptual view: there are N possible passwords (to simplify the exposition, ...


0

I use a small USB device of my own making that allows me to carry around a strong password "boost" on my key chain. Every password I enter anywhere is at least 15 random characters. For web sites I just tack on the first three characters of the web site domain at the end before I boost the seed to 15+ characters. Now, IF all web sites hash passwords then ...


-1

Just ask for strong passwords, not P4$$w0rDsTh4TW1lLn3V3RbEr3m3mB3r3D. Away with the special characters, and just write long plain sentences that actually can be remembered. Calculate the entropy instead of forcing inane rules on the form. I will never remember the stackexchange password I just created. I will just trust the browser to remember it, which ...


1

In addition to @rda's mention Shamir Secret Sharing, or @paj28's idea of an out-of-band authorization mechanism, you can also consider a much simpler solution, that does not require a lot of coding or setup: Use 2 factor authentication, giving each person a different factor. E.g. you give a hardware token to one, and a password to the other. The advantage ...


1

Two people with the same password (each knows a half) is not a good idea from a security perspective as each will have knowledge on the password. This would break by half their chances of guessing the other half with known attacks (brute-force, dictionary, ..). I would suggest Shamir's Secret Sharing. Each person would have a password and only combining ...


1

One approach is to use temporary passwords, and a password management application. The process could work like: An admin submits a request for access to a server for a particular time window A separate admin approves this request With the request approved, from the start of the time window the first admin can now access a temporary password for the server ...


4

Assuming your system is using regular simple unix authentication, there's at least one way of changing a password assuming you have root access. You can do this by simply editing the /etc/shadow file and pasting in a new password hash in place of the old one. This does not influence "chage -l" output as the change is done outside tools, so no other data ...


2

I agree with @schroeder that password reset emails are one of the areas where it tends to be more acceptable to instruct users to click on links. After all, the user was the one that triggered the password reset and should be expecting an email. You could add text in the email that says "This email was sent due to your request. If you did not request a ...


2

The token is just to verify that you received the email, that you own the account. Password reset links in emails are a convenience that provide proof that you own the email account and allow you easy access to the password reset workflow. These tokens don't have to live anywhere for long term and you can invalidate them after some missed attempts if you ...



Top 50 recent answers are included