Hot answers tagged

145

You don't. When you teach users to give their username and password to someone, you train them to be vulnerable to phishing or other social engineering attacks. Instead, design the system in a way that an administrator can view and edit these settings without requiring the users credentials. When you are in a situation where you really need to see ...


19

There are numerous "team password managers" that allow teams to share, change, and revoke access to credentials. Most are paid (or free for small teams), but this is likely the best way to go. They typically provide encryption, as well as access control over the access to specific credentials.


13

The only viable option I see (which hasn't been mentioned yet, odd) is to have the client setup account(s) with the appropriate permissions for you to use on these systems/internet services. This way, they handle the vendor relations and payment, but you have accounts that have the access you require. As Phillip's answer stated, you simply don't ask for or ...


11

I summarize the situation as following you need access to a third party service with account of your client meeting in person is not easily achieved a solution involving the client installing software or following a complex procedure is undesirable I think the best solution would be: Send a new password TO THEM You send them a password in a secure ...


5

Hashing client side Secondly assuming that the connection is compromised because of an MiTM attack. The process of how the leaked hash of the password is created is still unknown because the salt and iterations (based on the pincode) are unknown. In case of a MitM attack (made possible by say incorrect use of TLS) hashing client side will not help you. ...


5

Is wrapping MD5 in PBKDF2 (or, for what it's worth, other secure hashing algorithms) something that safely can be done, or are there better approaches for dealing with old, insecure MD5 hashes? Yes, it is secure. You do not loose any security on this process. All this passwords would experience the same protection that the non MD5 passwords have, given ...


5

From the homepage: A potent cocktail of AES-256 encryption and PBKDF2 key derivation ensures that no one but you can see into your data. Everything from your passwords to the addresses of your saved websites are fully encrypted whenever you aren't using 1Password. So it sounds like they derive an encryption key from you password using PBKDF2 and then ...


5

Keep it simple, but just use two forms of communication. For example, in an email requesting credentials, ask them to reply with username only and then text a temporary password to your number. As soon as possible after you get the credentials, change the temporary password to something else. Yes, in theory, someone could see the email and hack SS7 to ...


4

The inherent problem is that the computers are untrusted - multiple passwords going through the same untrusted channel won't really help, and may confuse your clients more than help them. I would strongly suggest adding a second factor authentication via a trusted channel like your client's smart phone. 2FA does not have to be onerous or complicated. Begin ...


4

There are literally tons of solutions for transmitting data (e.g., credentials) securely. If the client supports PGP / GPG encryption, you can exchange Public Keys and encrypt the emails There is also companies that specialize in SecureMail (ZixCorp) or you can purchase your own (Cisco Ironport). If you have a collaboration site (e.g., customer portal ...


4

Data entropy depends on the observer - there is no absolute measurement of entropy. It's even questionable as to whether or not anything in the universe it at all random, and "randomness" (or, more precisely, related to entropy, unpredictability) is the source or entropy. Unpredictability being the operative term: hard for somebody to predict. If you use ...


4

The proper way to calculate password entropy is to look at the password generation method, evaluate how much entropy is involved in the password generation method, and then evaluate how much of that input entropy is preserved by the encoding method. As an example, throwing a fair 6-sided dice once generates approximately 2.5-bits of entropy (note that it's ...


4

Yes, double hashing can be safely done, to give the older MD5 hashes more protection immediately. Just make sure you can distinguish such double hashes from regular hashes, and update them as soon as possible. The verification process should be done differently for the two kind of hashes, otherwise leaked md5 hashes could be used directly as password, tried ...


3

In general, use the maximum cost factor that is bearable from a performance perspective. I would create a benchmark application which is as close as possible to what your application does, and find out the cost factor on your production hardware that gives you the maximum tolerable delay. In most systems, I strive for a 10 to 20 ms delay. Assume your ...


3

Is there any reason to not do this? Yes, I think of two reasons not to do it: The user may mistakenly enter in their full-access password into a compromised machine. Once a user enters their lower-access password into a compromised machine, now the attacker potentially knows a username and can try to brute-force the other password. This gives the ...


2

The entropy of a password is a quantitative statement about the probability distribution of all the possible passwords. To simplify this, think of a probability distribution as a rule that, given a password, outputs the probability that that password is the one that was chosen. So you really can't put a number to the entropy of a password unless you start ...


2

The most secure way is to use a Trusted Platform Module. This is specific hardware made for storing keys and doing cryptographic operations. This is secure even against sophisticated attackers with physical access (e.g. the FBI), but you need specific hardware which will cost more. Without this, attackers may just read the key from memory. In that case you ...


2

KeePass describes some of what they consider here, and it is described with some more detail on page 18 of this excellent paper: Carnavalet, Xavier De Carné De, and Mohammad Mannan. "A large-scale evaluation of high-impact password strength meters." ACM Transactions on Information and System Security (TISSEC) 18.1 (2015): 1. It would be too long to ...


2

To answer your questions: Should all web applications implement such a security feature? This is just another good security feature to help the user so if the application can afford (resources not financially) to have this implanted in their system there is no reason not to. Is it desirable that companies store our historical passwords? Since ...


1

It would have a slight advantage that bots or attackers that haven't done their reconnaissance properly may be wasting time on password guesses with passwords that the system can't possibly accommodate. If an attacker can register for their own account, they should have checked the maximum password length and other password rules by trying to reset their own....


1

The only security disadvantage of password-length restrictions (I.e. "Not too large") is if the software is vulnerable to a buffer-overrun. Those are not difficult to defend against for password fields, so this is just laziness on their part. Other than that, password length restrictions can only artificially reduce the possible entropy in a password.


1

What version of Excel are you using? Since Office 2007, the encryption used in MS Excel is 128 bit AES with at least a 50,000 interation SHA-1 hash. If you use the built-in encryption with a sufficiently hard password you should not have to worry about offline attacks. How to define "sufficiently hard" will probably change slightly every few years, but if ...


1

Have you tried editing the field name using Saved Password Editor's "Edit" feature? Save the logon. Open it in Saved Password Editor. Select the logon, and click edit. You will see a box near the bottom labeled "Password field name". Paste in the name of the real password field. Firefox should be able to match it up after that. Of course, this won't ...



Only top voted, non community-wiki answers of a minimum length are eligible