I have a vb.net application that uses my gmail smtp server settings and my password to send me the users feedback through the email, (I don't want to show my email to the users)
The problem is I want to store these data securely in the vb.net application so that It's hard for any hackers/crackers through (reverse engineering or programs like cheat engine) to get my gmail account data.
Any ideas are welcome.
You cannot be 100% secure, you could store the email in a resource file and use an obsficator to make it much harder to get at the string but it is possible to break it (encrypted resource files and strings). However Even if you used a different email address and setup a forwarding rule the password for that account could still be comprimised. Anything you have access to in code a hacker could potentially break into as the key will be in clear text at some point.
You have a number of secure options:
Setup a webservice to receive your messages and email them onto you/log them to a database
Log your messages to a 3rd Party system (irc? news? some p2p network, IM system), and pick um the messages later.
Setup a Source Control/issue site for your system, google code/bitbucket/something else that has the ability to receive issues via an api.
I don't know if this makes any sense but what I'd do is let the program run an external PHP script that sends the mail.
Basically, if I'm understanding your question, you don't want the password in clear text in your .exe. Correct?
The solution is simply to ENCRYPT the string in your program, then decrypt it at runtime (pass your decrypted variable to your e-mail function).
Any two-way encryption will work. For example:
http://www.vbdotnetforums.com/security/1240-encrypt-password.html
As other people pointed out saving the password to your email in your application is unsafe because somebody might be able to crack your code and retrieve your password.
For logging errors, I suggest creating a very small PHP script and putting it on a PHP server. When an error occurs in your VB.NET application, the application can send data to this .php script. The script can save the data in a file or in a MySQL database.
All the things you need for sending data to PHP scripts can be found in "System. Net. WebRequest" namespace in VB.NET.
If you cannot use a PHP script, you may use a combination of IsolatedStorage ("System.IO.IsolatedStorage" namespace) and Cryptography ("System.Security.Cryptography" namespace) to save sensitive data. But, this is not completely secure to savvy attackers.
Related
I was wondering how secure this would be. I don't have full code for it right now, but I'll try to explain it in words.
When a login button is clicked, using socket.io, the username and password will be sent to a Node Js server. Once the server receives the username and password, it will check a text file, to see if there is a username and password that matches. If there is, the user data will be sent back.
Is there any way that someone could access the text file without direct access to the server? Would this be secure in general?
this will surely get closed as not a coding question, but I will answer anyway.
So you intend to include the user name and password with every request? THats a lot of repeated authentication, use a JWT instead. Use a well known library for auth (like auth0). If you want to make your own mAke sure you send it over https.
Can somebody read the text file?
Well
do NOT store the password, stored a salted hash. This is not reversible so even if the text file gets stolen it doesnt have the password
in theory nobody cam get at the file. In practice there is a huge gap between theory and practice. All the password breaches you hear about are 'bad guys' accessing a file /db that nobody thought could be got at
Let's say I have a program written in VB.Net with encryption code that relies on a key being set to encrypt and decrypt. How do I securely store the key in the program? If it's plain text in the code, it could be reverse engineered. If it's a setting, then it is stored as plain text in the x.exe.config file and even easier to find.
Can the x.exe.config file be set to encypt? If not, what's the safest way of hard coding the key into the program?
The method I've used is encrypted using a different method, then encode that (as it's non-ascii text) and store that in the settings, but that in turn could be decoded if the program is reverse engineered.
What do other people do in this situation?
You've set to an impossible task. The problem is that by hardcoding the key into the program, as you've noted, the user can still get the key by reverse engineering. If you put it in a file somewhere, the program needs to be able to read it, and therefore the user can also access it in the same way.
The fundamental problem you have is that the software needs to access the key, and for that, the key must be stored somewhere it's reachable by the user too. It can be within the binary or in the computer, but the binary can be analyzed and the file system can be inspected. Encrypting a file protects the key, but just recreates the problem with the new key.
This is also the very same problem that all DRM schemes face. They give users access to the the full software but want to limit it in some ways, but the user has everything in his computer to run the software. That's why it's always possible to pirate every desktop software, if enough effort is put towards it. You only can make it more difficult by obfuscating the key.
But what can you do then?
An alternative approach is to not have the user to have the DB credentials at all. Or make them useless for anything significant. I can think of two approaches here:
Have the system communicate with a webservice and never to the DB directly. This way, the user only knows the address of the server and the WS can request any authentication as needed, before going to the DB. The WS is then the only one to ever touch the DB. This is what all websites do in practice, the visitor doesn't ever sees the DB, but interacts with it though the web server.
Another option would be to give the user direct DB access, but those credentials only give permission to call some stored procedures (or access views without sensitive data) and those in turn request some sort of authentication before proceeding. This way the DB credential becomes not that sensitive as long as its permissions are kept to the bare minimum and privileged actions are properly validated before proceeding.
I am planning on creating a little web service to host on my site, but I would like to know how to create a simple, secure login form (username + password) for just one username + password combination, without using SQL. This doesn't have to be super-secure, but it would be nice if you couldn't just crack it by peeking at the source code. Can this be done?
You could just use Basic Auth?
http://en.wikipedia.org/wiki/Basic_access_authentication
You can use Berkeley DB. It is a key-value database that is stored in a file. It does not have a server, but it supports concurrent access. Just make sure to put the file outside of where your webserver will serve it (in other words, not next to the CGI script that users are accessing).
Edit: The asker clarified that he wanted something extremely simple to implement with a "limited understanding of web design". In that case, put the username and password in a text file (plain text, JSON, CSV, whatever your programming language can parse the easiest) in a place where your webserver won't serve it, and make it readable only by the webserver. You should also hash the password (that link is for PHP, but it will be very similar in other languages).
Do you have some kind of server-side scripting? It's not possible in JS.
Since you said it doesn't need to be completely secure, you can basically use hashing and salting to create something which can't be "cracked" by looking at the source. Be aware that if you aren't connecting over https, a malicious users in your local network, ISP, government, etc will able to eavesdrop on the communication and see you transmitting a plain-text password. For this reason alone, the password shouldn't be re-used anywhere and the implications of someone else logging in should be low.
Here's a crude example of how to generate the hash:
<?php
$salt = "can-be-anything";
$password = "password";
$hash = hash_pbkdf2( "sha256", $password, $salt, 1024, 0 );
echo $hash;
?>
and our result is 5b24ad89b5e94c35537f6967b39cf294aa845f94440ebfdd3e857e4cf5f41d7e. Now you can just follow the same procedure when receiving the password and compare the two hashes. If you reduce the number of iterations it will be easier to brute-force the hash, but will reduce server load.
Pros
Can store the hashed password inside the same file
Someone looking at the source can't learn your password
Complexity to break the stored password scales with password length
Cons
No guarantee of security, someone could eventually gain access
If not using https, an attacker could learn your password from passive network monitoring
You can also use an OAuth provider (facebook, google, twitter, linked in) and even enable two step verification.
It's really easy to set up, here is an example on PHP using google:
https://github.com/google/google-api-php-client/blob/master/examples/idtoken.php
And here another using facebook:
https://github.com/facebook/facebook-php-sdk-v4/tree/f1916f3a1e8aeece518a18dc88f05775aadb9840/examples/login-logout-get-profile
Both google and facebook have apis for all major languages, but you can also use any standard oauth client if you prefer. Or even implement you own one, the client is actually fairly simple.
I want to write a google chrome extension, that should make a request to my website to send and get some data, so, actually I should do an ajax request like it is written here https://developer.chrome.com/extensions/xhr.html
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://api.example.com/data.json", true);
I wanted ask if there is a way to somehow secure the code or prevent others from using my api, because actually the other users can see the source code of the extension when they install it and so use my api without me being aware of it.
EDIT:
If I need to make some sort of authentication, than how can I authenticate the user before making the ajax call ? for authentication I will need to send a request to my server , but for that I should send , e.g. username and password, that should be saved somewhere in the extension's files, which, in fact, can be seen by the users, when they install the extension.
Thanks
Don't trust the browser, take steps to authenticate the user instead. So, in this case, you could require that YOU enter in a password that is used to communicate with your server.
Your Google extension would simple require you to enter in a password before it attempts to use AJAX to communicate with your server.
Be aware that you should build in means of protecting yourself from brute-force attacks. So, do things like lock everything down if there are more than some small number of wrong passwords, etc.
You could also consider using the password to simply decrypt the destination of the XHR, but if you go this route, you should store this very carefully, because this will be brute-forceable offline.
EDIT
Trying to lock down an API so that only a single application can use it is just not practical nor technically possible, so you're only hope of doing this is to authenticate the user using the API, regardless of the accessing software he is using. You could have the user sign an agreement that legally limits them to only your extension, but I suspect this will go largely unenforceable and will consume your time tracking abusers down.
If you don't want unauthorized people even knowing where the API is, you could perform authentication using an out-of-band mechanism: over the telephone, email, SMS, or simply, another API that will grant the user a password or token that requests to your API must be accompanied with.
During this out-of-band process, you could also grant the user, a unique URI (the API access point) that is only valid per authenticated session (https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/, for example). Any requests to your server on OTHER URIs simply won't work. However, this isn't theoretically much different than using the same API access point, and having a good password. It just changes the number of places in your architecture that will be performing authentication and/or authorization checks.
<aside>My vote would be to reduce the number of authorization/authentication points to as few as possible so that you can spend more time on getting that one place correct rather than having multiple places and possibly multiple logic flaws or other things that could lead to vulnerabilities.</aside>
You could also explore using Public Key Infrastructure and/or one-time passwords schemes or device-based token generators, etc., but in the end, you'll be allowing authenticated and authorized users to use your API. And, thanks to the Internet, this will not remain an undisclosed URI for long.
And, more importantly, it will not prevent someone from using the data on their own. Even with all these measures in place, it would be trivial for an authorized user to collect this data as it is being streamed to your extension. Or, if you employ point-to-point encryption, they could screen-scrap or use some form of JS introspection on your very code or even extract the data from their computer's memory.
I know you were looking for a silver bullet here, but it doesn't exist.
I think you are doing it wrong. You should never trust what's going on on internet users PC's. Never!
Move the line of trust one step inward, make your API public and then design the security where you have perfect control - server side.
I could not get correct aspect of your use case
Few Points:
Your extension code is always traceable( Any one who has installed extension can view the code)
If you are looking for security through complicated or obfuscated coding patterns you end up slow down of understanding process not the whole.
If your target is to ensure users who install your extension should be able to access and inert all other users( Who have gained illegal access or downloaded and edited code) have a session shared key per installation.
Please explain further use case so i can help you better.
Should the HTML5 database be used to store any form of private information?
Say we have the following scenario;
You're browsing a web-mail client, that uses the web database to store mail drafts after you've written some information you close the web browser. What's to stop me from getting access to this information?
If the webpage tries to clean out old information when opened a user-script could easily prevent the website from fully loading and then search through the database. Furthermore the names of databases and tables are easily available through the web-mail client's source.
W3C Draft
The only way an external party could access the user's database is via direct access to the user's computer, or if your web app has a security vulnerability (such as XSS - Cross Site Scripting). Otherwise standard browser security dictates that only scripts running in web pages from a certain domain can access databases that were created/stored on that same domain (same origin-policy), same thing that stops you making cross-domain Ajax requests, or reading other website's cookies, all of which can be overcome via an XSS attack.
To me, storing a draft email seems reasonably sensible, whereas things like credit card details, passwords etc. should be stored exclusively server-side. You'll need to make a call as to what should be stored where, based on what you're going to store.
Should the HTML5 database be used to store any kind of private information?
Depends on how sensitive the information is. I wouldn't want to leave credit card details lying around anywhere.
You're browsing a web-mail client, that uses the web database to store mail drafts after you've written some information you close the web browser. What's to stop me to get access to this information?
Assuming you don't have physical access to the computer (in which case the user needs to take relatively extreme security measures) and you don't run the email service (in which case you need to have access to emails) then standard browser security stops you.