Suggestions for how and where to maintain and protect client passwords...
As someone that manages a handful of small business networks, what is a Best Practice for maintaining and securing customer sensitive data such as their passwords belonging to their server's admin account, firewall password, network switches, and registrar login portal credentials, etc...? Last century, a good old fashion Excel Spreadsheet used to be the way to go but, I sense there is a better and more secure way but, haven't found "the way". Any solid suggestions here would be appreciated.
Shaun Vermaak
Keepass http://keepass.info/ with a proper master password or key file
You would need to describe your usecase a little more.
How does it look when you use these passwords, where are they entered on?
If I imagine you are a external supporter, you will maybe logon from remote using RDP. Saving the RDP password to the RDP client and then keeping the rest of the passwords in a password vault (such as keepass) on a machine at their site (that is accessed from remote) could be a better idea than to keep all passwords for all customers in one password manager file at your site. It depends.
Password managers have weaknesses, too. Let me describe a scenario that you need to be aware of: Imagine you have keepass open and thus have access to all passwords. A trojan that you execute unknowingly then would possibly have the same access - there are malwares that harvest passwords right from memory (in the case of keepass, that is called "keefarce" attack). So keeping all passwords of all customers in the same file is maybe not something your customers will even want - think of them, too.
How does it look when you use these passwords, where are they entered on?
If I imagine you are a external supporter, you will maybe logon from remote using RDP. Saving the RDP password to the RDP client and then keeping the rest of the passwords in a password vault (such as keepass) on a machine at their site (that is accessed from remote) could be a better idea than to keep all passwords for all customers in one password manager file at your site. It depends.
Password managers have weaknesses, too. Let me describe a scenario that you need to be aware of: Imagine you have keepass open and thus have access to all passwords. A trojan that you execute unknowingly then would possibly have the same access - there are malwares that harvest passwords right from memory (in the case of keepass, that is called "keefarce" attack). So keeping all passwords of all customers in the same file is maybe not something your customers will even want - think of them, too.
Memory harvesting and the like are not an indication of weakness in KeePass.
You would have had the same issue if the password was written down on a piece of paper and stored in Fort Knox yet typed into a vulnerable computer.
You would have had the same issue if the password was written down on a piece of paper and stored in Fort Knox yet typed into a vulnerable computer.
Right, this is not a vulnerability that you can patch. Still something that you need to be aware of when handling password vault softwares.
Be aware of the difference, though: to harvest the password from keepass, keefarce would not need administrative rights (nor elevation) - it works right away. For harvesting a saved RDP password from the windows vault, you need interaction with the user or administrative rights+elevation.
Be aware of the difference, though: to harvest the password from keepass, keefarce would not need administrative rights (nor elevation) - it works right away. For harvesting a saved RDP password from the windows vault, you need interaction with the user or administrative rights+elevation.
No, you do need administrative rights
https://www.pentestpartners.com/blog/concerned-about-keefarce-dont-be-why-you-should-still-use-a-password-vault/
https://www.pentestpartners.com/blog/concerned-about-keefarce-dont-be-why-you-should-still-use-a-password-vault/
KeyFarce isn’t really malware; you have to be an admin to get anywhere near using this properly and if you are a privileged user you don’t need these tricks: just use a sniffer, install a certificate, install a key logger etc. and you’re in.
My Proposal is to keep the Excel spreadsheet but force/advise the customer to zip/rar it with a custom password measuring more than 8 chars with combination of letters/numbers/special chars
Archives with strong passwords require a lot of time to hack especially they are meanigless like "Kd!gi@Pr0g+"
Archives with strong passwords require a lot of time to hack especially they are meanigless like "Kd!gi@Pr0g+"
@Shaun
No, please try it for yourself. Keefarce does its thing without administrative rights nor elevation. The linked article is wrong.
No, please try it for yourself. Keefarce does its thing without administrative rights nor elevation. The linked article is wrong.
@McKnife
Will give it a shot
@John
The problem is that the unprotected Excel file will be in temp folders and the solution is fragmented. For example, if protected Zip is on server and admin click on it, firstly he/she extracts it, works on temporary file and might even make changes. If another admin does the same their changes will overwrite one another.
Will give it a shot
@John
The problem is that the unprotected Excel file will be in temp folders and the solution is fragmented. For example, if protected Zip is on server and admin click on it, firstly he/she extracts it, works on temporary file and might even make changes. If another admin does the same their changes will overwrite one another.
@McKnife
You are right if KeePass runs as user it is possible without elevation but I easily prevented that by running KeePass as admin but this might not be solution for all
I have to stress however that this holds true for all processes, not just KeePass
Thank you for pointing out the error, valuable to know
You are right if KeePass runs as user it is possible without elevation but I easily prevented that by running KeePass as admin but this might not be solution for all
[.] Injecting BootstrapDLL into 16228
Process found, but OpenProcess() failed: 5
[.] Done! Check %APPDATA%/keepass_export.csvI have to stress however that this holds true for all processes, not just KeePass
Thank you for pointing out the error, valuable to know
@Shaun ...there are always cases that something can go wrong...the idea is the OP to have them (the archived spreadsheets) somewhere on his drive/cloud and when some kind of access is needed the client would log on and extract the archive...and decrypt the excel......present it and close the spreadsheet...delete it...
I just checked ...at least with WinRAR there NO leftovers on the Temp folder...
I just checked ...at least with WinRAR there NO leftovers on the Temp folder...
No OP said "Last century, a good old fashion Excel Spreadsheet used"
WINRAR and the like deletes files but they can easily be recovered
WINRAR and the like deletes files but they can easily be recovered
My random password "Kd!gi@Pr0g+" would take 57337 years, 10 months to crack it.....cool...:)
Yes but every computer that ever opened that ZIP will have the deleted file ready for recovery unless those sectors have been overwritten
If there is a concern for this you could have 2 spreadsheets one normal and one fake...with the SAME name....each time you need something then you extract the good one and then after the job is done you overwrite it with the fake one....delete the fake....the possibilities get a bit low that someone can recover the original good file....
IF there is a need for something more elaborate then the discussion is getting to a whole level where is not so advisable that the client should give the sensitive data to a 3rd party....or design a solution that requires 2 or more password keys to "reveal" the required info....with hash coding and cryptography....
IF there is a need for something more elaborate then the discussion is getting to a whole level where is not so advisable that the client should give the sensitive data to a 3rd party....or design a solution that requires 2 or more password keys to "reveal" the required info....with hash coding and cryptography....
The two spreadsheets are not a solution because they can write to different sectors and both can be recovered.
PS: Check password strength at http://passfault.com/.
It seems passfault is fast....the others give different numbers...
You meed to change algorithm but none really apply
Also about the other methods mentioned...if the info is too valuable there other ways to retrieve it....even the best encryption method has little chances against social hacking....
Personally i believe that if you have information too valuable to someone he will find a way to steal it...the less people process the info the less are the chances....
Personally i believe that if you have information too valuable to someone he will find a way to steal it...the less people process the info the less are the chances....
This seems more accurate http://www.tomshardware.com/reviews/password-recovery-gpu,2945-8.html
Do you use a system like ConnectWise? I will concede right off the bat that it leaves something to be desired from a security aspect, but otherwise it at least serves as a central repository for an MSP.
ASKER
Wow, there's quite a bit of good feedback on this post. I'm going to look into some of the tools mentioned above but, not interested in storing vital password information on someone else's cloud.
@John, I used to use a spreadsheet but due to the fact that I am constantly mobile, opening and closing a spreadsheet is inefficient time wise.
@masnrock, I use a similar platform and have hosted it myself for quite a while. However, I think I am going with a classic form of password protection mentioned in my last paragraph after reading a good tutorial on cryptography.
After reading an insightful tutorial on cryptography, I'm leaning toward using my Contacts in Outlook. Should be much easier to access and I'll will be using a form of "Shifting" so that if my Contacts are ever compromised despite having a very lengthy and complex password to Outlook, the passwords will not be what they appear to be displayed.
I'll leave this post open until tomorrow so that if someone has a suggestion with taking "shifting" one step further, post it.
@John, I used to use a spreadsheet but due to the fact that I am constantly mobile, opening and closing a spreadsheet is inefficient time wise.
@masnrock, I use a similar platform and have hosted it myself for quite a while. However, I think I am going with a classic form of password protection mentioned in my last paragraph after reading a good tutorial on cryptography.
After reading an insightful tutorial on cryptography, I'm leaning toward using my Contacts in Outlook. Should be much easier to access and I'll will be using a form of "Shifting" so that if my Contacts are ever compromised despite having a very lengthy and complex password to Outlook, the passwords will not be what they appear to be displayed.
I'll leave this post open until tomorrow so that if someone has a suggestion with taking "shifting" one step further, post it.
You didn't reveal much about your use case but only wrote that you are constantly moving. Did you consider the thought to have decentral password stores at each site that you connect to (if you connect to those and don't work on-site but from remote, that is)?
How many people would require access to the passwords? You're mobile, but what about the others?
ASKER
@McKnife "maintaining and securing customer sensitive data such as their passwords belonging to their server's admin accounts, firewall security appliance passwords, network switches, and registrar login portal credentials, etc..."
Yes, each customer is on a different network and a different, LLC, Inc., etc...
Like I posted earlier, I'll explore some of the recommendations above but for now, adding password shifting to each customer's passwords will suffice for now. Besides, why would anyone want to risk keeping Actual Passwords? I guess there is an abundance of independence on other tools and programs when security methods are built right into us.
@masnrock, myself and my partner/wife.
Yes, each customer is on a different network and a different, LLC, Inc., etc...
Like I posted earlier, I'll explore some of the recommendations above but for now, adding password shifting to each customer's passwords will suffice for now. Besides, why would anyone want to risk keeping Actual Passwords? I guess there is an abundance of independence on other tools and programs when security methods are built right into us.
@masnrock, myself and my partner/wife.
"adding password shifting to each customer's passwords will suffice for now" - could be :-)
But then again, if it should be something that is usable with longer passwords, it will be quite complicated, your manual shifting - or it will be easy to guess how you shift if someone sees all shifted passwords.
Maybe... I don't know how you'll go about.
Just wanted to add that thought of decentral pw storage because if I was in your customer's position, I would ask you not to keep my passwords in a central password vault that is constantly opened.
But then again, if it should be something that is usable with longer passwords, it will be quite complicated, your manual shifting - or it will be easy to guess how you shift if someone sees all shifted passwords.
Maybe... I don't know how you'll go about.
Just wanted to add that thought of decentral pw storage because if I was in your customer's position, I would ask you not to keep my passwords in a central password vault that is constantly opened.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I would not use Contacts, it is not designed for this
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You can use authentication itself as a password, meaning, if you used a tool like CyberArc, Thycotic or Centrify - those systems handle the "actual" PWD's, and all you need is permission to use them. Permission equates to knowing your own password. I'll cover these 3 in particular as well in the article.
There are other systems too if your just managing windows local passes, SHIPS from TrustedSec and M$'s own LAPS.
-rich
There are other systems too if your just managing windows local passes, SHIPS from TrustedSec and M$'s own LAPS.
-rich
As promised: https://www.experts-exchange.com/articles/29079/Password-Managers-Password-Vault.html the enterprise version is still WIP.
-rich
-rich