The simplest thing to do is employ a dead man's switch that sends vital information to someone that you trust, and have established an agreement with to carry on or conclude a select few of your affairs or ventures if something should render you unable to continue with them.
In the simplest case, you have something set up to send an email to several people ...
Here are a number of simple steps which will make it easy for someone to take over after you are gone:
Give clients plenty of time to figure it out. Don't register domains for only one year at a time, go longer. Domains are fairly cheap and there is little reason to choose shorter-term registration.
For client websites, record all necessary details that ...
It's not about emailing plain text passwords vs. a URL, it's about storing passwords in plain text vs. hashing them. Storing passwords in plain text is not considered secure because if the site (or server, or database...) is exploited, the hacker has access to the user's account on that site along with any other site on which they use the same username and ...
You could bruteforce the hash that is stored in the database.
WordPress uses phpass for hashing. Per default, WordPress does not use blowfish or similar, but just md5 with an iteration count of 8192. If you just want to find really bad passwords, bruteforcing is certainly feasible.
But I would consider this a rather big violation of ...
If you're emailed your password and three months later someone gets access to your email, they can get into your account (unless you've changed the password, which is unlikely). If you're emailed a password reset link and three months later someone gets into your account it won't do anything, because even if you've not used it, it will have expired. It ...
Your assumptions are generally true. But without looking into the cPanel code myself, I don't know what the actual situation is. However, there is such a thing as locality-sensitive hashing.
Unlike a normal hashing algorithm, where you want even minimal changes to produce huge differences, locality-sensitive hashing produces hashes that reflect the ...
Without storing the passwords you can only evaluate the quality by counting the number of different types of character (upper case, numbers, special characters) when the user first sets or subsequently resets their password.
You could enable the counting and store that information (you just need the number of characters and the number of each type of ...
There is no simple solution to this problem. Static passwords may be shared among friends. Tracking mechanisms (IP-addresses, cookies) will turn up "false positives" (i.e. rejecting real paying members) - which is very bad for business.
Using a OTP (One Time Password), as suggested by Steve, is probably not practical, as it does not allow casual use, and ...
Based on the fact this is is a .com domain, you can do the following:
Go to https://www.verisigninc.com/en_US/domain-names/com-domain-names/index.xhtml.
Click on the Chat with Support link at the bottom of the page. Explain the situation to them and tell them what documentation, if any, you have to establish that you or your client is the rightful ...
I'm not sure that this is even possible. When you select your password, it's stored hashed in database. There's no reverse enginering when comes to hash algorithms.
In my experience, script for password strenght is located in www.example.com/wp-admin/js/password-strength-meter.js, and this is the link to it.
You can change levels and percentage for ...
If we are ignoring everything else you mention, (i.e. shared computer, firefox saved passwords, etc.) the "show" password feature is, by itself, not a security risk. It is for convenience and the "everyday user". There is nothing stopping someone from using the build in browser inspector and changing it to an input type textbox from password. It serves the ...
Apart from the obvious security issue of someone else being able to physically see what password you are typing - which the user would be aware of anyway - there are a few security "concerns" that could arise with how it is implemented and what (trustworthy) software is on the users system, that could potentially expose the password to third party apps/tools ...
If any of your clients post the URL in just about anything, search engines will likely discover it. They may also find it while crawling domain registration sites and the like...
As Google states here:
If you need to keep confidential content on your server, save it in a
password-protected directory. Googlebot and other spiders won't be
The good news are that you can change users passwords, the bad news are that you cannot see them.Wordpress is so powerfull that even in the database it stores the password with one way encryption it's not just an md5 hash you can convert, it's not even serialized data, for the password test123 you would get something like $P$BjW8o9Dm1vC5bwAcP1iAdNVm0lbvn, ...
As the passwords are hashed, the only way to test their security is to brute force them. Gather a list of commonly used, weak passwords and test them against the hashes stored in your database.
Unless you use a very exhaustive password list this won't catch all of the weak passwords, but it will filter out the weakest of them.
This is a question that only you can answer.
If your web-hosting provider and their choice of control panel is returning your password in plain text formatting, it would suggest that they don't take the security of their platform seriously.
Typically, a good hosting provider will provide security in depth. That is, multiple layers of security ranging from ...
Best way to do this, is to create a script that would log in to SMTP account by PHP, with SSL. If the process succeeds - set a cookie/session and let him go on.
Here is some code snippet PHP SMTP mailer
You don't need most of it, just the top part where it try to log
A simple solution on the Apache server side is using Basic access authentication.
See the section "Getting it working" for an example. And here some answers on Stackoverflow.
Pro: If you have access to the command line and your webserver it's a 2 minute set up that blocks access to your project.
Con: Managing access this way for many users might be ...
It's a security measure on so many levels!!!
I. Typing it twice is to make sure you entered it correctly!
What if you entered it just once, made a typo and didn't notice?
The site might have a ToS preventing multiple accounts for the same person/email!
You might never be able to login to that account/website ever again!
II. Passwords should NEVER be ...
Sounds like you are reinventing the wheel. There are plenty of scripts that will check password quality http://www.webresourcesdepot.com/10-password-strength-meter-scripts-for-a-better-registration-interface/
It is pretty difficult to implement something like this. You can't do it based on IP number because most people have dynamic IP. Even if it was only some people, you would have a problem.
You could do it via a cookie, but I reckon you are creating a support nightmare for yourself as some people don't accept cookies, people delete cookies. Besides, what ...
Sadly without running a brute force which I can't advise on you can not since cPanel is normally setup to use ProFTPD and PureFTP both of these servers used hashed passwords and they are not viewable in any form - if it's your server just reset the password.
No - Joomla! does not store the password.
It stores a hash of the password with a salt.
To reset the password you could use one of the tools on the Joomla! Extension Directory (JED) in the Security Section.
We tend to do it manually, but I've heard that people have used the "Reset Admin Password" tool successfully.
It appears that Chrome now ignores autocomplete="off" unless it is on the <form autocomplete="off"> tag (which applies to the entire form). You used to be able to add the tag to any <input> field, which gave you a lot more control.
You may also need to start the document with this DTD:
You should change the password immediately. There are several reasons for this:
If the account has been compromised allowing the old password will mean that the account is still compromised and the attacker will be able to change it again.
Every other system changes the password immediately, so this is what the user will be expecting.
If you allow the old ...
According to this forum thread your database password is not stored in the database. It is stored in a configuration file.
For Joomla version 1.5
It will be in the configuration.php normally on line 54 'var $password =' 'yourpassword';
For Joomla version 1.0 it will also be in configuration.php but you need to look for
$mosConfig_password = '';