How to create a strong password - BlowFish

[lainz]

Hi, I'm using TCollection Streaming to store a TComponent, I've changed the code to support BlowFish encryption.

http://wiki.freepascal.org/TCollection#Streaming

The code works fine.

As you can see, my current password is just 'WsXpx98Pkbaxw6HU9sexFQPE'. And yes, is stored as you can see in the code. (Wrong, right?).

How I can generate a strong password and put it in a way that can not be easily readed inside the application? I don't need to be super secure (Just using this not to be plain text or binary with strings that can be easily readed in the output filenames and executable).

This is the code:

Code: [Select]

uses
  BlowFish

procedure TBalanceComponent.SaveToFile(AFileName: string);
var
  en: TBlowFishEncryptStream;
  ComponentStream: TStringStream;
  EncryptedStream: TMemoryStream;
begin
  ComponentStream := TStringStream.Create('');
  WriteComponentAsTextToStream(ComponentStream, Self);

  EncryptedStream := TMemoryStream.Create;
  en := TBlowFishEncryptStream.Create('WsXpx98Pkbaxw6HU9sexFQPE', EncryptedStream);
  en.WriteAnsiString(ComponentStream.DataString);
  ComponentStream.Free;
  en.Free;

  EncryptedStream.SaveToFile(AFileName);
  EncryptedStream.Free;
end;

procedure TBalanceComponent.LoadFromFile(AFileName: string);
var
  de: TBlowFishDecryptStream;
  ComponentStream: TStringStream;
  EncryptedStream: TMemoryStream;
begin
  EncryptedStream := TMemoryStream.Create;
  EncryptedStream.LoadFromFile(AFileName);

  de := TBlowFishDecryptStream.Create('WsXpx98Pkbaxw6HU9sexFQPE', EncryptedStream);
  ComponentStream := TStringStream.Create(de.ReadAnsiString);
  EncryptedStream.Free;
  de.Free;

  ReadComponentFromTextStream(ComponentStream, TComponent(Self), @OnFindClass);
  ComponentStream.Free;
end;

[taazz]

Wow! I understand the need and to tell you the truth I have it on my todo list for quite some time now to take a closer look on how all those "secure local sotrages" work (ee kwalet Gnome Keyring, Windows DPAPI ,apple keychain etc.) but never actually convinced my self to spend the needed time on it yet. The only thing I have to say is don't use any static password every time you save the data create a new make sure that enough information are stored somewhere to be able to recreate the password when reading the data back. That said the field of which data are secure enough and stable enough to create random passwords every time you want one, becomes the next battle field on this war.

In your position I would use the existing solutions (as previously said DPAPI on windows using functions like https://msdn.microsoft.com/en-us/library/windows/desktop/aa380261%28v=vs.85%29.aspx this one) would be my go to solution for now they have far more resources to work with than your application including the current users credentials.

[munair]

One way is to feed your password to an encryption algorithm and store the encrypted version in a specific file (or in your code if you settle for a static one). Using RC4 with a specific key is still one of my favourites and you would still give NSA guys some work to decrypt your 256 bytes encryption.

[BitBangerUSA]

not sure what you are asking...

you want to generate a strong password AND store it securely in your Application file meaning the password will change each time the program is run?
or do you want to do a one-time strong password and store that for use each time the program is run?

in either case, these are two separate tasks - meaning separate code to handle each one.

secure passwords are easy enough to generate. securely storing it is a different critter. and you might want to consider obfuscation of your code that *uses* the password.

you did say you don't need to be 'super secure' - whatever that means. if you only want to spend a certain amount of time and effort on the 'security' i can guarantee that it won't be very secure. but, you have to balance your effort/time against the effort/time an attacker might need and also against the value of what you are securing.

[lainz]

I see all different comments and see that is not that simple to be secure.

The only thing I have to say is don't use any static password every time you save the data create a new make sure that enough information are stored somewhere to be able to recreate the password when reading the data back.

It sounds reasonable. Just my code is doing the wrong using a static password and storing it as plain text inside the executable.

secure passwords are easy enough to generate. securely storing it is a different critter. and you might want to consider obfuscation of your code that *uses* the password.

Yes thats the point. I recently readed in other forums ways to store and generate a password inside pascal but there are a lot of different ways to do.

Code: [Select]

you did say you don't need to be 'super secure' - whatever that means. if you only want to spend a certain amount of time and effort on the 'security' i can guarantee that it won't be very secure. but, you have to balance your effort/time against the effort/time an attacker might need and also against the value of what you are securing.
The data is not as sensible to spend a lot of time on it.

not sure what you are asking...

you want to generate a strong password AND store it securely in your Application file meaning the password will change each time the program is run?
or do you want to do a one-time strong password and store that for use each time the program is run?

in either case, these are two separate tasks - meaning separate code to handle each one.

Well the second. At least at this time. A strong password that is reused each time the program is run. The password will be used to store and retrieve encrypted data as shown in the code of the first post.

BTW I'm thinking that if the program don't use a password for accessing it the data will be available for everyone that can access the executable. A combination of both I think will be the best solution.

[engkin]

CryptProtectData sounds like an invitation for attackers.  I am not convinced that it adds any security against, let's say, some attacker dropping a fake dll - Crypt32.dll maybe - in the installation directory with the goal of replacing CryptProtectData function with:

Code: [Select]

pDataOut := pDataIn;

I might use it to fool an attacker to think that I depend on Crypt32.dll while in fact the real encryption is in my code. In this case pDataIn is already encrypted, and the attacker has to find out where and how it was encrypted.

I would take my chance and assume that most attackers are good with attacks but not with programming, and build my defense based on that.

[Nitorami]

Storing a password within the executable is a very bad idea, as everyone with access to the exe can read your data. This is not a very smart approach, even for moderate security requirements. The only way to do it safely is to make the program ask YOU to enter a password.

[ahiggins]

Just on a general note, when storing passwords whether that be in the executable or an external data file is it better to store a hash of the password? or is it just as safe to store the whole thing? 

[lainz]

Storing a password within the executable is a very bad idea, as everyone with access to the exe can read your data. This is not a very smart approach, even for moderate security requirements. The only way to do it safely is to make the program ask YOU to enter a password.

Yes. I think it's the best solution. The data will be only accessible with that password, like mysql databases does.

BTW I'm thinking that if the program don't use a password for accessing it the data will be available for everyone that can access the executable. A combination of both I think will be the best solution.

[goodname]

My understanding is that your going to have to create the valid password in memory at some point during execution to pass to
TBlowFishEncryptStream.Create(getObscuredPwsd(), EncryptedStream);
When this happens there are programs that can watch values in memory for running programs. If you know what your looking for you can get the password using these programs no matter how much you obscure the password in the non-running binary executable.

[Nitorami]

@ahiggins
NEVER store a password in plain text, but a hash only. This is how password databases work, the password of each user is hashed before storage. This needs a secure one-way hash function which does not allow to reverse calculate the original password from the hash. SHA1 or RIPEMD should be safe even nowadays, MD4 has a flaw and is not. The only computationally feasible way to retrieve the original password from the hash is by guessing, i.e. the attacker would feed random words into the hash function until the result matches the hash stored in the database. Bingo.
A standard PC can grind through a whole dictionary within a few seconds, therefore it is increasingly important to make passwords long, complex and unguessable.

[taazz]

Just on a general note, when storing passwords whether that be in the executable or an external data file is it better to store a hash of the password? or is it just as safe to store the whole thing?

When storing passwords yes its better to store and check against a hash but in this case we are not talking about a password but an encryption key if you only store a hash you essentially through away the key and you can't decrypt the data any more.

[Nitorami]

Yes, but we can generate an encryption key from a password, and it may not even be necessary to store anything, neither key nor password. Consider we simply calculate the 160bit SHA1 hash of a plain text password and use this as encryption key for blowfish or similar, without storing it. It will then not be possible to check whether a correct password has been entered, but this is not necessary for this case. If a wrong password has been entered for decryption, the decryption sequence will simply deliver undecipherable garbage.

[taazz]

Yes, but we can generate an encryption key from a password, and it may not even be necessary to store anything, neither key nor password. Consider we simply calculate the 160bit SHA1 hash of a plain text password and use this as encryption key for blowfish or similar, without storing it. It will then not be possible to check whether a correct password has been entered, but this is not necessary for this case. If a wrong password has been entered for decryption, the decryption sequence will simply deliver undecipherable garbage.

there is no password entering anywhere in the current process. simple an encryption today and a decryption tomorrow. No one is allowed to know about the encryption process.

[taazz]

Mac address is a unique constant that can be used to generate an encryption key as well as the windows installation key and of course the creation date of the file can be used to salt it. take them as a concatenated string and calculate some hash from them (SHA1 would be my choice) and use that to encode the file. It will keep the casual hacker out of the data

My understanding is that your going to have to create the valid password in memory at some point during execution to pass to
TBlowFishEncryptStream.Create(getObscuredPwsd(), EncryptedStream);
When this happens there are programs that can watch values in memory for running programs. If you know what your looking for you can get the password using these programs no matter how much you obscure the password in the non-running binary executable.

I really would like to know what kind of programs you are talking about.