Is information stored in www.onenote.com (OneNote Online) encrypted or can you force the information to be encrypted? I like the idea of being able to access your information from any device, but a little hesitant about the kind of information to store if it is not encrypted or you cannot force the encryption.
OneNote supports adding another layer of security by password protecting a section (More details).
Do note though that you have to use a desktop client one time to set the password. But once set, you can use OneNote Online to enter the password and access your notes.
Related
I recently logged into a website (student run club website which stores event and participant information).
After successfully logging in the following message appears and follows me around for the rest of my time on the site:
You are using an insecure password. The password that you entered has
been exposed in at least one data breach.
How do you know my password is insecure? This password appears in a
database of known passwords. Hackers may use this password to try to
break into your accounts.
While I appreciate the notification that my password was compromised (and should know better and will change and stop reusing passwords etc etc) I now worry about the overall security of this site.
I don't know a terrible lot about web dev but my naive assumption, given this message and the fact that it appears after log in, is that my password must have been stored in plain text for them to be able to check it against a database. Is this correct? Or is there some clever secure way this could be done?
Just because you are receiving a notification from the site doesn't mean that your passwords are being stored in plaintext. Whatever website you are using can use your password in the "Have I Been Pwned" API before encrypting them. This of course doesn't necessarily mean that they are encrypting them as there isn't really a surefire way to know how they are storing your passwords without possibly contacting the owner or if you were to receive an email at a later date with your password in it.
You can read up on the API for password checking here haveibeenpwned.com/API or you can check for the website you are using in this list here haveibeenpwned.com/API/Consumers.
I am trying to solve the classical approach to how user login pass token is stored in web browsers. By default, anyone who can access the developer's consoles of the browser can obtain the content in password fields by looking at the HTML content of the input element or using javascript.
Because of this, if by mistake someone comes across your login password, he/she can use it on any browser to access your data from the server.
To solve this problem, I am researching a way which on an attempt to login the server will generate a unique pair ID from the client's Unique ID and let the client store this server generated ID as the user's login pass for this client only, such that if the server generated ID is used in attempt to log in from another browser, the server will compare the associated browser ID to the accessing unique ID before permitting access.
Consequently, A server generated login can only be valid on the client who generated the ID, the real password is never stored on the client, but only used on the first attempt to login on a client who does not have valid server ID. The user will have the opportunity to invalidate all the server-generated pass.
For this to work, I need a unique token from the browser such that if 10 instances of the same browser are installed on the computer within a time-space less than 1 second, the ID of this browsers will never be the same.
My question is, can such Unique ID be obtained from the browser? any suggestion on how to go about this is also appreciated.
In general, you can't uniquely identify a browser installation in the way you describe. This is, in part, to protect users' privacy from tracking across the web.
Your ultimate goal (preventing an attacker from authenticating if they discover the user's password), however, can be satisfied with a one-time-password system, like TOTP.
In a system like this, when an account is set up for one-time passwords, the user and service share a secret. Later, when the user logs in, they are prompted for a one-time password, which they generate using special software, which is isolated from the client, and ideally on another device. For example, the user might use the Google Authenticator app on a smartphone to generate a code that they enter on their desktop browser.
Even if the attacker captures the user's conventional password with a key logger, they can't authenticate themselves because they don't have access to the shared secret necessary to compute the one-time-password.
Universal 2nd Factor authentication is another approach to thwart key loggers based on some parallel concepts. (That is, it also uses a one-time code, generated with a secret that is securely stored rather than being exposed on the client.)
I want to build a VB.NET application that will connect to a MySQL database.
I was thinking of putting the MySQL password on the My.Setting file, but that's easy to read. Which would be the safest way to put the password on the program?
I don't want to ask for it on start-up, I want it to be embedded on the software, but WHERE?
Wellll..... If it's stored in an automatically program-readable format (aka, the user doesn't have to enter any kind of password or credential to enable the application to make use of said database password), then there isn't exactly a "safe" way since any kind of meaningful encryption requires that the user enter some credential to retrieve the encrypted information. You could store it in a module as Base64 text for obfuscation, but that's not really "safe." At all. It's just encoded differently (NOT encrypted).
The bigger question to me is, is the environment safe? On the back end of a website for example, the password for sql databases is usually stored in-the-clear in the php config files... but that's because the environment is secure: php source cannot be obtained by the public, and trusted users with access to the backend are assumed to be non-malicious.
So, that raises some questions:
Where is the application running from?
Where is the MySQL Database, local or remote?
How many people have access to this database or will be using this app?
These are all considerations that should be accounted for.
One other thing - if you're building a .NET application, there are certain .NET code-obfuscators out there that play with your compiled code to make it quite difficult to pillage once compiled. This may be of interest to you. I believe Dotfuscator ships standard with Visual Studio? You can register for a free account with them.
My client wants to store his login in the Adobe AIR application. Is this a good idea? I've looked at using Encrypted Local Storage (which uses the operating system) or is there another method more suitable?
I've found this answer but it is very confusing, https://stackoverflow.com/a/11899254/441016. It is saying it is OK to use to store login information but not OK to store registration keys for licensing software. I don't understand that. Login is more important than registration keys.
It's saying that other applications can read that information. Does that mean my application can read sensitive data from other applications simply because the user is logged in? That doesn't sound right. If an application adds sensitive data to the keychain it should be the only application that can retrieve it.
You should use the Encrypted Local Storage for saving login information in the device, it's save and easy to use.
If some user is able to see the contents in the Encrypted Local Storage (ELS), all he will see, is his own login info, so there isn't a security risk here. However, if you save registration keys or API keys, the user could use this information to hack your App.
Hope this helps.
I just realized that there is no best way to hide MySQL string connection password in my executable file, especially in JAR file. Even encrypting it in EXE would only slow down the process (although I'm not sure how much time would it take to get an encrypted password from an EXE file).
So, from my understanding, I need something in the middle that would do the add, edit, delete etc to the database. Seems like a job for REST API or maybe SOAP services.
My question is, which one should I use? Or should I use something else? I was thinking Zend Framework to create those REST APIs. Then, I would use Qt to create a desktop application to call those APIs. But if I proceed with REST, my application would be a 3 tier application. Wouldn't it be better if I just create a web application? Maybe I should just stick to desktop application call those APIs since the application is already finished and I just need to change from connecting directly to MySQL to calling those APIs to perform tasks rather than changing the whole application to a web.
Any advice would be very helpful. Thanks in advance.
UPDATE:
I'm looking for a security that would protect my MySQL password connection.
Obfuscator would only obfuscate the code, it won't hide my string database information which In my opinion can be easily found using grep after decompiling the JAR using tools like JAD.
About my application:
Using a centralized MySQL database
Thousands of user
Contains sensitive information
My client uses Linux and Windows
My server uses Linux
All access are done in LAN, no outside connection (from Internet etc)
My current solutions (comments please):
Using REST APIs (safer since MySQL password is in the server)
Using Qt with encryption to the password
It depends on what kind of security are you looking for. Is this to protect the application from the user? To protect the user's data from other users? To protect multiple users' data from one another? To protect the user's data from an attacker?
In a lot of applications there's nothing wrong with storing the database login credentials in plain text. In other cases, you might try:
encrypting a user-chosen database password using a reasonably strong algorithm, e.g. Blowfish, using a hard-coded key;
having the user provide the password and "log in" to the program each time;
storing the database password in plain-text, but encrypt the data using a hard-coded key;
same as the above, but encrypt each user's data using their own provided password;
same as 2 but store each user's data in their own database with their login info as the database credentials;
storing the data on a secure remote database that users have to log into to access via a SOAP API;
using the native filesystem permissions to protect the configuration file holding the login credentials;
same as #1 but rolling your own really elaborate key-generation system: e.g. run the machine SID or a hardware id through MD5 using a randomly-generated salt, and then using the result to encrypt the login credentials.
Remember, there's no such thing as perfect security, so whatever you settle on doesn't need to be unbreakable. It just needs to be tough enough to break to make the hassle of circumventing the security mechanism exceed the value of the data. So, for example, if the data is a list of the top scores in Minesweeper, then ROT13 would probably be enough.
Edit:
I just want to add that, even if you can't get around having to hard-code an encryption key in your application, there are obfuscators for Java, .NET, and most other popular languages/frameworks. One of the key uses of these tools is to hide sensitive hard-coded strings like encryption keys.
Edit 2:
Given the additional details about the app in question, only 1, 6 and 8 would apply in this case. And a SOAP API is more appropriate for #6 as George rightly pointed out.
I also want to mention that there are Java resource obfuscators that encrypt string literals. This is just one example.
It pretty much depends in what environment your app runs
a) db and client local
b) db and client in a local network
c) db is in the internet
my two cents:
a) I would create a single db user and wouldn't use a password but restrict acces to localhost
b) direct connect to the database is fine but I would each user have to login with his own password and grant only the permissions he needs.
c) It's a bad idea to allow mysql connections to a public server. In this case webservices would be a good solution.
Anyway if your case is b or c I would stick with a login dialog for the user.
Maybe you should have a look at this http://www.greensql.net/ tool.
It is like a firewall but for mysql/postresql
So you can deny anything and only allow queries you want to.
If you are using Java for implementing your database desktop application, I would recommend to use Java DB as the database. There is a few ways of securing it, and there are alternatives to having a password in the connection string. I would recommend to read Java DB Security - Security Features in Java DB Release 10.4
It is easy to deploy your application with Java DB, since you can have much of it embedded in the same jar file. I have used it in a Point of Sale application implemented in Java.