New answers tagged

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 ...


0

I will need to explain some things before answering your questions. Okay, so password can be 2 things, by that I mean it can be just Authentication or it can be Authentication with Encryption. Just Authentication: just Authentication means that there is just one wall of defence between files and the user who is trying to access it. Just Authentication ...


0

Another situation if you store your encrypted password file in the cloud is in the rare situation where your cloud provider gets shut down, like https://en.wikipedia.org/wiki/Megaupload did for copyright infringement; some legitimate companies had data on that site in addition to all the illegal movies, etc.


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....


0

My question is, is there any actual security advantage to forcing a character-limit on password-reset, and then allowing unlimited characters on login? I can't see any security benefits to that. Allowing unlimited length at login is probably not a concsious design decicion, but rather the result of the developers not bothering to set the maxlength property ...


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.


0

Strange that noone mentioned OAuth, which, at first glance, is the perfect solution for the problem, as rephrased after the update.


0

The website of Bruce Schneier's password safe is pwsafe.org. It is free open source software. But it is by far not the only password manager on the market. I could list three others just on top of my head, and I am quite sure there a dozens of others on the market.


0

While this may be beneficial to the user, think of the impact of that password being compromised. Instead of saving your user a few seconds for every login, your alternative is a breached account which can mean a loss of funds, identity, and creates more work for yourself and/or your team if/when reported. Do yourself and your users a favor and do not ...


0

You shouldn't be hard-coding callbacks th respond to specific username/passwords. If you are dealing with 3rd party tools you should be setting up those accounts for them and interacting with those tools via API tokens. Much better that you create the account and at the end assign any account credentials over to the customer.


0

It's 2016, so it's well worth revisiting this 5 year-old question. There was a Password Hashing Competition conducted from 2013 to 2016, which accepted 24 submissions and selected Argon2 as its recommended password hashing algorithm. Everything that Thomas said about new vs. good still applies. As recently as February 2016 (after the end of the contest) ...


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 ...


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 ...


0

Use a key derivation function (e.g. PBKDF2) to create an encryption key for a cipher (e.g. AES) used to encrypt your password file. It provides protection against brute force attacks (admittedly PBKDF2 isn't the best KDF, but it's widely available). BUT beware of things like the data finding it's way into the page file or in a temp file somewhere.


0

Relying all your security in a single file is dangerous. The file can be easily decrypted even if you use strong passwords. The reason is because the amount of attacks that can be done per second is incredibly high (more if you consider that a copy of the file can be attacked by multiple computers at the same time). As Alexander pointed out, there is ...


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 ...


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 ...


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. ...


0

The local hashing will not help against passive MitM if the authentication process is simply sending the hash to the server. The attacker can capture the hash during registration/password change and just send a request with the hash instead of using your web application which computes the hash based on password and pin code. Server side hashing keeps ...


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.


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


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 ...


-3

Since KeePass is released under GPL, you can potentially prevent KeePass from specialized attacks by changing the implementation. Implement a method that displays the window title of the window that KeePass will send the password to. That way you have the chance of detecting that it's an incorrect window. Implement a method to detect quick focus loss and ...


0

Stealing data from the memory is definitely easier than stealing it from an encrypted file. You can take a dump of your memory and then scan it to search the password. On a side note, I believe the bigger risk here is that there is a very simple mapping between the seed and the password. Also, the seeds seem to be predictable. Once that is compromised, do ...


0

There are many password "managers" that works in that way. For example Masterpassword app is really close to your idea. The algorithm is open source so I disagree with @RonWayn. As long as you cannot reverse the algorithm and find the master password with a given used password this should be secure enough.


0

It's only as secure as the master password. Everything else relies on the the assumption, that the algorithm is not disclosed to an attacker aka security through obscurity. Oh, and you just disclosed your algorithm to the internet.


0

Passwords are user facing data. If you have a "password" that is neither set nor used by a user, it's called a "key" or a "secret" (exact terminology varies by use). So you need to research key storage, not password storage. There are two parts to securing a key: Choose a cryptographically secure random key. Something like 128 bits from a CSPRNG will do ...



Top 50 recent answers are included