Using fstream, what file type would you recommend that I can read and write to for save files? I'm attempting to make a program where the user enters a username and a password and it'll output it to a file. I'd like a filetype that isn't very easy for the user to edit. (so not a .txt or .ini)
Thanks in advance
fstream doesn't really have a sense of a "file format" outside of being in text mode vs pure binary mode (there are some nuances with newlines for example). You would typically use some sort of intermediate library to generate or directly write XML files, JSON files, INI files, etc. SQLite is a popular library/format to store database tables in a file. Mozilla Firefox uses it for their bookmarks and history for example.
What you're talking about is security through obscurity. By using using some sort of encoding, perhaps ultimately binary so it wouldn't even be printable at all without a hex editor, it would obscure things a bit. If you used encryption it wouldn't be readable until decrypted, but you could always reverse engineer the program to determine the encryption/decryption keys and algorithms.
The most secure option is to not store the password at all, but a hash of the password. This means that even with reverse engineering the program, you wouldn't be able to directly extract the stored password. Instead, whenever the user attempted to enter a password, it would compare use the same hashing algorithm and compare the results.
This doesn't always work though, because sometimes you are storing the password to submit to a 3rd party, in which case you do have to ultimately recover the stored password into plaintext for transmitting to the 3rd party.
I hope this gives you some ideas!
Related
I am doing this small university project, where I have to create a console-based text editor with some features, and making files password protected is one of them. As I said, it's a university project for an introductory OOP course, so it doesn't need to be the most secure thing on planet. I am planning to use a simple Caesar cipher to encrypt my file.
The only problem is the password. I'll use the password as the encryption key and it will work, but the problem is handling the case where the password is wrong. If no checks are placed then it would just show gibberish, but I want to make it so that it displays a message in case of a wrong password.
The idea I have come up with is to somehow store the hash of the unencrypted file in that text file (but it shouldn't show that hash when I open the file up with notepad) and after decrypting with the provided password, I can just hash the contents and check if it matches with the hidden hash stored in that file. Is it possible?
I am using Windows, by the way, and portability is not an issue.
In general, you can't theoretically design a data format where nothing but plain text is a valid subset of it, but there can also be metadata (hash or something else). Just think about it: how do you store something other than text (i. e. metadata) in a file where every single byte is to be interpreted as text?
That said, there are some tricks to hide the metadata in plain sight. With Unicode, the palette of tricks is wider. For example, you can use spacelike characters to encode metadata or indicate metadata presence in the way that the user won't notice. Consider Unicode BOM. It's the "zero-length space" character. Won't be seen in Notepad, serves as metadata. You could so something similar.
They already mentioned alternative data streams. While one of those could work to keep the metadata, an alternative data stream doesn't survive archival, e-mailing, uploading to Google Drive/OneDrive/Dropbox, copying with a program that is not aware of it, or copying to a filesystem that doesn't support it (e. g. a CD or a flash drive with FAT).
Working on a Qt application on embedded linux which requires to store the username, password kind of sensitive information.
I'm currently using QStringLiteral to store this info. Is this safe to do? These aren't visible when ran against strings binary. What are the available options / solutions?
SqlCipher is available but again it needs a password / key. Any suggestions
You should never store passwords! There is no way to do that securely, not in Qt nor in anywhere else!
I would recommend you to generate a random number/salt, add the password from the user and run a secure hash on that data. For example MD5, or even better SHA1 (thanks to Ted Lyngmo). Store the result. Then you can even take a plain text file as it is very hard to get from that data back to the original password.
If security is not that big for you, you could use something like:
QString result = QString(QCryptographicHash::hash((password+salt),QCryptographicHash::Md5).toHex());
and safe the result in QSettings.
I'm writing a project on arduino and I'm storing a password in a const char array. This password is written in the code and I would like to hide the password from malicious readers who have access to the .o files and .hex files.
Does anyone happen to know how to hide it?
I allready tryed by storing it in a const byte array instead of a const char array, but it doesn't seems to solve my problem...
The tricky part is that no matter what, since you need to use the password, (and I'm assuming you can't enter a key every time you boot) your code is going to contain both the lock, and the key to opening it. The real question is how good does this have to be?
If it doesn't have to be real good, you could xor the password by some value, and use that as the password in the source. You then xor it by the same value when you need to use it, and ta-da...
If you want something less trivial (and the arduino fits it), you could sign the password with your private key, and store your public key in the source. The algorithm to unsign the password is considerably more complex than a simple xor (thus harder to spot.)
No matter what, any self-contained system that needs to use plaintext passwords is compromisable.
You could store the password in EEPROM, which you can write to with avrdude or inside your code. In the latter case you will need to provide the password to your device at some point after flashing.
The password will still be accessible to anyone with physical access to the device, but not people who only have access to .o and .hex files.
I am not sure if the Arduino bootloader allows you to read and write EEPROM through avrdude, but if not, you could write an initial Arduino sketch that writes the password to EEPROM, then later overwrite it with your actual sketch that only reads it.
Just hash the password and store the hash. Than you hash the user input password to try and match them.
Now, if you need to store a password to another service and you can't help but use the plain password with their API, then you have few possible choices.
I'm working on a wxWidgets GUI application that allows the user to upload files to an FTP server and a pair of username/password is required to access the FTP server.
As far as I know, STL strings or even char* strings are visible to end user even the program is compiled already, using hex editors or maybe string extractors like Sysinternals String Utility.
So, is there a safe/secure way to store sensitive informations inside a C++ application?
PS. I cannot use .NET for this application.
This is actually independent of the programming language used.
FTP is a protocol that transfers its password in plain text. No amount of obfuscation will change that, and an attacker can easily intercept the password as it is transmitted.
And no amount of obfuscation, no matter the protocol used, will change the fact that your application has to be able to decode that password. Any attacker with access to the application binary can reverse-engineer that decoding, yielding the password.
Once you start looking at secure protocols (like SFTP), you also get the infrastructure for secure authentication (e.g. public/private key) when looking at automated access.
Even then you are placing the responsibility of not making that key file accessable to anyone else on the file system, which - depending on the operating system and overall setup - might not be enough.
But since we're talking about an interactive application, the simplest way is to not make the authentication automatic at all, but to query the user for username and password. After all, he should know, shouldn't he?
Edit: Extending on the excellent comment by Kate Gregory, in case that users share a common "technical" (or anonymous) account accessing your server, files uploaded by your app should not be visible on the server before some kind of filtering was done by you. The common way to do this is having an "upload" directory where files can be uploaded to, but not be downloaded from. If you do not take these precautions, people will use your FTP server as turntable for all kind of illegal file sharing, and you will be the one held legally responsible for that.
I'm not sure if that is possible at all, and if, than not easy. If the password is embedded and your program can read it, everybody with enough knowledge should be able to do.
You can improve security against lowlevel attempts (like hexeditor etc.) by encrypting or obfuscating (eg two passwords which generate the real password by XOR at runtime and only at the moment you need it).
But this is no protection against serious attacks by experienced people, which might decompile you program or debug it (well, there are ways to detect that, but it's like cold-war - mutual arms race of debugging-techniques against runtime-detection of these).
edit: If one knows an good way with an acceptable amount of work to protect the data (in c++ and without gigantic and/or expensive frameworks), please correct me. I would be interested in that information.
While it's true that you cannot defend against someone who decompiles your code and figures out what you're doing, you can obscure the password a little bit so that it isn't in plain text inside the code. You don't need to do a true encryption, just anything where you know the secret. For example, reverse it, rot13 it, or interleave two literal strings such as "pswr" and "asod". Or use individual character variables (that are not initialized all together in the same place) and use numbers to set them (ascii) rather than having 'a' in your code.
In your place, I would feel that snooping the traffic to the FTP server is less work than decompiling your app and reading what the code does with the literal strings. You only need to defeat the person who opens the hex and sees the strings that are easily recognized as an ID and password. A littel obscuring will go a long way in that case.
As the others said, storing a password is never really save but if you insist you can use cryptlib for encryption and decryption.
Just a raw idea for you to consider.
Calculate the md5 or SHA-2 of your password and store it in the executable.
Then do the same for input username/password and compare with stored value.
Simple and straightforward.
http://en.wikipedia.org/wiki/MD5
http://en.wikipedia.org/wiki/SHA-2
Although the PDF specification is available from Adobe, it's not exactly the simplest document to read through. PDF allows documents to be encrypted so that either a user password and/or an owner password is required to do various things with the document (display, print, etc). A common use is to lock a PDF so that end users can read it without entering any password, but a password is required to do anything else.
I'm trying to parse PDFs that are locked in this way (to get the same privileges as you would get opening them in any reader). Using an empty string as the user password doesn't work, but it seems (section 3.5.2 of the spec) that there has to be a user password to create the hash for the admin password.
What I would like is either an explanation of how to do this, or any code that I can read (ideally Python, C, or C++, but anything readable will do) that does this so that I can understand what I'm meant to be doing. Standalone code, rather than reading through (e.g.) the gsview source, would be best.
A plugin for GSview for viewing encrypted PDFs is here.
If this works for you, you may be able to look at the source.
If I remember correctly, there is a fixed padding string of 32 (?) bytes to apply to any password. All passwords need to be 32 bytes at the start of computing the encryption key, either by truncating or adding some of those padding bytes.
If no user password was set you simply have to pad with all 32 bytes of the string, i.e. use the 32 padding bytes as the starting point for computing the encryption key.
I have to admit it's been a while since I've done this, I do remember that the encryption part of the PDF is an absolute mess as it got changed significantly in nearly every revision, requiring you to cope with a lot of cases to handle all PDF's.
Good luck.
xpdf is probably a good reference implementation for this sort of problem. I have successfully used them to open encrypted pdfs before.