Tag Info

Hot answers tagged

39

Yes, this is the standard practice. Doing anything other than this offers minimal additional advantage, if any (and in some cases may harm the security). As long as you verify a valid SSL connection to the correct server, then the password is protected on the wire and can only be read by the server. You don't gain anything by disguising the password ...


12

As long as you verify the certificate validity, this is perfectly fine and is done all the time.


8

Not necessarily. You also need to ensure the following: Your site is protected against cross-site request forgeries. Your site is protected against session fixation attacks. If using cookies, that your entire site is HTTPS, not just the login URL, and that your session cookie is marked as secure and http only (no JavaScript access). You are using a ...


7

Most of the sites usually considered to be secure take pretty much the approach you are describing. Or put differently, you have simply described established industry standard. I would recommend against using an approach less secure than the one you mention. (Whether bcrypt is better or worse than other salted hashes is a discussion I won't be going into. ...


4

I just logged into cPanel and when I click to change my password it asks me for three things: My old password A new password Confirmation of the new password Screen Shot: It also says that the old password cannot be empty. This may not be exactly how cPanel does it but, it is a possibility: Since you have sent it your old password to cPanel it can ...


3

it depends on how you plan to use the answers. If you expect to do strict automatic checking then treat them as passwords and apply key-derivation function such as bcrypt/scrypt. (But remember, that BCrypt uses only first 72 characters of string for the hash. is that enough for your case?) on the other hand, if there is a chance of phone-based support and ...


3

As others have said this is a standard approach. However for a personal site I wouldn't necessarily follow it... I would use federated login from Facebook, Google or similar as that way I don't have to handle account life-cycle issues, and can use Google 2 factor Auth etc. It saves having quite a few forms and fields in your database which means less to ...


2

@Travis Pessetto most likely has the correct answer to your question. I just wanted to point out that some places will do this without knowing your old plaintext password. This can be done by generating permutations of your new password and comparing each hash to your old password hash. Old Hash (Plaintext Unknown): ...


2

Am I at risk doing this? No If "pass" is safe, meaning it is doing encryption correctly, you could send your encrypted passwords to anyone you want and you would still be fine. As long as they are not able to crack your master password with brute force but this might takes years if you have a strong master password.


2

What you describe is a witty password: a password which relies on the user knowing some specific generation method. This is bad. Witty passwords are not secure passwords; they more are quite the opposite. When you use a "witty password", you rely on the attacker being less smart than you. Self-confidence notwithstanding, this always fails. Attackers know ...


2

HTTPS makes the authentication request unsniffable in transit. However, to make it "safe", there are other things that you also need to get right. For example: The entire login page and all of its dependencies should also have been served over HTTPS, even though no password is being transmitted then. Serving any part of it (such as JavaScript, CSS, or ...


1

I've never heard of a specific name for these types of password transformations. However, they often involve the use of a "master password" and "site password". You can do some searching based on those terms and filter out the irrelevant results. Here are a few examples of similar schemes that are implemented through software: ...


1

Security through obscurity (like "hidding" the administrator's account under another name) at most could delay a few minutes any attack, but does not increase your real level of security at all. Root accounts usually cannot log in remotely and in most cases their password are disabled by default, so any attack using "root" as username will not succeed on ...


1

Many flavors of linux (e.g., ubuntu) by default disable password login to the root account, but let the primary account elevate to root permissions by prefixing commands with sudo and entering that account's password. https://help.ubuntu.com/community/RootSudo


1

I use 1password for this you can have a shared account which you sync via an exrypted file shared by Dropbox



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