Since Chrome saves passwords and cookies locally, and doesn't care much about preventing them from being decrypted and stolen by malware, I would like to make sure that malware (but not Chrome process) cannot access the path where chrome saves passwords and cookies.
Is there any way to do it?
Probably a perfect solution does not exist because the administrator account has all the privileges so any process on this account can access any file on the disk, but since the malwares are programmed to perform certain generic tasks for each pc (e.g. search passwords and cookies in the default path of chrome), if I on my pc change certain things the malware he would not know how to overcome the obstacle.
So what I need is not a perfect solution that can be installed on any pc but something that at least works on my pc. Thanks.
Related
I have a winforms application that connects to a database with a connection string and a generic user
"Database=DBADAS;Server=TMT123\\SQLEXPRESS;User ID=user; Password=*****;
After connecting into the database with a login dialog, we check if the user and password are existent in the user table from the database.
My question is now if this is a good practice? because basically in the connection string there is every information needed to crack the server.
There are a few ways to go about this safely. Since it's a Winforms app and not a web application, most of your security risks involve someone already in your network peeking at the connection string. This adds a layer of security in and of itself.
1. Hardcoded
You can hardcode the connection string that fetches the users into a DLL and make your application depend on that DLL. I only suggest this because it sounds like the "generic user" password is permanent; otherwise, you'd have to recompile code every time you changed the password, then deploy again. This is very secure, however, as the value isn't stored in plain text.
2. App.Config
You can stick it in a configuration file. Within a secured network, this is probably the most versatile option, as you can store multiple strings and easily update them without updating the full application. This goes well alongside settings like a "DebugMode" setting, etc. Using App.Config or another XML file is ideal, but you can roll a quick and dirty .txt file, too.
3. Database
Probably the most secure way of all, as you can encrypt your database and code your programs to fetch their connection strings and login information from that database by using an unrelated login. This allows greater control over what can be reached by the application when a user has not yet logged in. It also prevents the software from operating outside of the network, which may be desirable.
4. Internal API
Having a separate application serve this data divorces user capability from your concerns, as the API and your app can exchange verification keys to see if your app even has permission to try to connect. This is my personal favorite, but obviously the most work to set up.
5. Registry Entry
Depending on how you have this installed, it may work well to embed the tokens you need in the Registry. This guarantees the app requires admin permissions to install, and allows you to use Windows security to restrict access to the hive.
Again, since it's an internal non-web app, I wouldn't worry too much about the plain text of the connectionstring; if someone has gotten this far into your network, chances are you have much bigger problems already. I wouldn't leave it floating as a plain text file in a local directory, but any degree of security above that is probably acceptable for your purposes.
Encrypting Web.Config
Open Command Prompt with Administrator privileges
At the CommandPrompt, enter:
cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
In case your web Config is located in "D:\Articles\EncryptWebConfig" directory path, then enter the following to encrypt the ConnectionString:
ASPNET_REGIIS -pef "connectionStrings" "D:\Articles\EncryptWebConfig"
Use Aspnet_regiis.exe tool with the –pef option and specify the application path as shown above.
Note: The parameter "connectionStrings" is case sensitive.
For Winforms: You need to rename your app.config to web.config encrypt it by using steps 1 to 3 and again rename it to app.config.
Reference: https://www.codeproject.com/Tips/795135/Encrypt-ConnectionString-in-Web-Config
I want to write a batch file for a usb pen drive which retrieves my stored passwords from my firefox browser and backs them up on the usb pen drive. Is there a command which can retrieve these passwords and, if so, is it possible to save the results to a txt file?
Thanks,
oblique
I don't think you would want to store your passwords as plain text on a USB drive. What happens if you misplace your USB drive?
If you want, you could backup your profile folder using a batch file, and that would include not only your passwords, but also bookmarks, extensions, etc. Mozilla documentation gives advantages/disadvantages to using the password manager inside Firefox.
One advantage of using the Firefox Password Manager is that it stores
all your logins - your usernames and passwords - in one single place.
You can find your logins in the Firefox Password Manager and not worry
about forgetting where they are.
On the other hand, putting all your logins in one place, unprotected,
can be risky. Theoretically, someone who has access to your computer
could open and view your logins in the Firefox Password Manager and go
on an Amazon shopping spree ! Fortunately, Firefox lets you use a
master password to prevent others from accessing your logins without
your permission.
It also recommends external password managers, but oddly, it doesn't mention KeePass. You could use it to store your Firefox passwords(or any other passwords for that matter). You can download the portable version and run it off your USB drive.
We got PDF files that are only allowed to be viewed in the office. Some users keep those files in the flash drive disk and bring them home or send them to their email. What'd be the best way to prevent this situation. Taking a screenshot of screen is still enabled.
Network : 100 Mbps LAN-based
Number of concurrent users to view file
: Around 50 at a time.
If a user can read a file, he can copy it. You definitely need a piece of software to act as the go-between. There are a few software solutions out there that use DRM encryption to protect your PDF files. Some claim to prevent screen captures as well.
In your situation, you would probably want to have the DRM software check for a license certificate server on your network to ensure they are at the office before letting them open the file. This would allow them to still use take-home thumbdrives and laptops to get work done.
Try searching for "PDF DRM" and see what you find.
I have an windows application (WPF) in which we are running on each login, however when the user first logs into a new PC the application will need to do some specific tasks, but only on the users first login and never on subsequent times.
Is there a way in .Net 3.5 to query wether the user has logged in before (ie some kind of login count)?
Failing any native support I will create a txt file in the users registry however I wanted to know if there is a native way of achieving this first.
We use redirected folders so the user may have already logged into a PC on our network these special events should only occur when the user hasnt logged in onto the PC and Windows has had to create a new profile for the user on the PC.
If I am not clearly explaining what I am seeking, please dont hesiate in letting me know.
Matt
Failing any native support I will create a txt file in the users registry however I wanted to know if there is a native way of achieving this first.
I'd recommend going with this option. Don't try to detect it, just create your own state on first run.
I suggest this, not because it is technically impossible to achieve the functionality you describe, but because it is a better user experience. It provides an easy way to re-do the action without having to recreate the user.
... a txt file in the users registry ...
I'm not sure what this means. You can create text files under the user's profile directory, and you can insert string values in the registry (but not files of any sort).
As for the particular mechanism, I suggest you consider:
An App.Config value. Clearing out the value is easier to support or batch-script than a registry value, and makes the user less scared that their machine will explode if you have to tell them to edit the settings. Users are scared of the registry.
A sentinel text file under the user profile directory. Wiping out the file is super-easy to support and batch-script. Instead of editing a text file, they can just delete one. But this makes it so you have multiple config mechanisms, so multiple points of failure. I'd only do this if I were using the App.Config for additional settings in the program and thought the user wouldn't be technical enough to hand edit it.
The windows registry. Remote registry access might be easier than remote file access, if you're having to do remote troubleshooting. It also might be easier to mess with via group policy, in case this is an intranet app and you need to force a re-run on all machines in your org.
I'd carefully consider my options and which is most likely to ease support (be understandable by my users) before committing to one. I'd also consider the remote-troubleshooting/remote reset scenario.
This may not be what you're looking for but I'm hoping it will help you anyway.. I do not know from the top of my head how to do this in WPF but I do know you can use an "unattend.xml" file and the FirstLogonCommands to execute a script or application on first logon. I have used this for Windows 7, it may not apply to XP.
I have a page on an intraweb (that I didn't create) which allows a user to specify a .txt file and then it writes the results of a SQL stored procedure to the file using StreamWriter.
It apparently stopped working for some of my workstations several months ago, so I can't trace it to any specific changes (However, I know the code itself didn't change).
If I access & use the page on the server (where the wwwroot and applicable database are located), it successfully writes the .txt, whether I specified a local file or on a workstation on the network. Users on some workstations,though, are no longer able to write to a file.
(It is also not just writing a blank file. The "Date Modified" remains unchanged.)
The problem seems to be machine-related rather than user-related, as I can login as the same user on different workstations with different results.
I still think it may have something to do with permissions, so I created a .txt on a problem workstation with every possible account having full permissions, but no luck. Permissions on the database, stored procedure, and folder destination seem correct.
Any suggestions welcome, Thanks.
You mean to tell us that the page completes with success, your calls to StreamWriter all succeed, and yet in the end there is no file? I find that really hard to digest. A much more likely hypothesis is that the page fails and exception is thrown. Such an exception would be logged normally in the system event log.
From the description of your symptoms the issue could be a constrained delegation scenario: the page is impersonating the IE user and it cannot flow the credentials to whe accessing the network resource.
It turned out to be the IE security setting "Include local directory when uploading files to a server". This setting is disabled by default.
The working PCs had the setting enabled for some reason. Adding the site as a "Trusted Site" also enables the setting, achieving the same result.