Tag Info

New answers tagged

0

I think one of the main reason people advise to move away from Filezilla is clearly the fact passwords are stored as plain text and thus, easilly stolen. Filezilla bad reputation began some years ago when some malwares began to target specifically Filezilla. Using critical flaws in third party softwares (namely flash and acrobat reader) these malwares were ...


0

I would tend to agree that this is primarily a compliance-driven requirement with at best a marginal net increase in security (at, unfortunately, a substantial cost in loss of operational availability, due to otherwise legitimate users being locked out after 90 days, machine-to-machine communications failing because their passwords expired and nobody updated ...


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


0

You are talking about either a witty (or clever) password or a key derivation algorithm (that is being shoehorned in to producing a "concealed" password). Neither provides any additional security beyond the original password complexity. Either the system is insecure because it is too simple and able to be reverse engineered, resulting in catastrophic ...


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


0

From the perspective of having such a simple answer like a mother's name protected ,for example, on the web server side - the answers are more than likely hashed in there. The same story is for your local machine, for which you administrator password, be it even so simple, as mother's name, is also kept in hash form. So, keeping the hash instead of the ...


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


0

Have a user-configurable boolean value for "reset allowed". If you have their e-mail / some out-of-band means of communicating with the end user When the user clicks the "I forgot my password" link, if "reset allowed" is true, send a password reset link to the e-mail account associated with the user account. Make sure you use an e-mail service that first ...


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


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


0

nope. because, strictly speaking, nothing prevents you from renaming root-account on Linux too. the name is just a record in /etc/passwd file. it might lead to some incompatibilities in software, but that should be rare.


0

No. Just because there is an alias to something from an app's sandbox container does not mean the App has access to it -- that's still controlled by the app's entitlement list (and I strongly suspect Apple would reject any app that requested direct access to a user's keychain files). Also, even if it could access the file directly (as a non-sandboxed app ...


0

If you just used a hash of your password, your hashed password would become your de-facto new password. If used on more than one site, it is similar to reusing your normal password, although it's hopefully harder to guess it or brute force it. In practice, you want to mix a salt (to protect from rainbow tables) and website name (to protect from reuse) into ...


1

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


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


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


0

We have to wait for the conference to start for more information. But my first thoughts: the wifi and entertainment systems should be separated from the control systems. It should not be possible to just find a password and then control the plane (or parts of it) from you personal computer. At least make an attacker get out of their seat. passwords should ...


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


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


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


12

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



Top 50 recent answers are included