Recent

Author Topic: The most easy encrypting/decrypting password method?  (Read 15402 times)

balazsszekely

  • Guest
Re: The most easy encrypting/decrypting password method?
« Reply #45 on: October 02, 2021, 09:05:01 am »
I edited my previous post. Try to get the last os error.

Conte

  • New Member
  • *
  • Posts: 27
Re: The most easy encrypting/decrypting password method?
« Reply #46 on: October 02, 2021, 09:28:09 am »
'Incorrect parameter!'
Crap!

This is my current code pastebin.com/NdVL1k9x
« Last Edit: October 02, 2021, 09:33:09 am by Conte »

balazsszekely

  • Guest
Re: The most easy encrypting/decrypting password method?
« Reply #47 on: October 02, 2021, 10:12:39 am »
Quote
Incorrect parameter!'
This message makes no sense to me. Anyways I' m out of office until Monday so I cannot help. Maybe somebody else can test the code, if not I will take a look Monday.

Conte

  • New Member
  • *
  • Posts: 27
Re: The most easy encrypting/decrypting password method?
« Reply #48 on: October 02, 2021, 10:26:44 am »
It looks like an error that returns from the windows credential manager? Maybe it worked to your that have windows in english language.
« Last Edit: October 02, 2021, 10:32:27 am by Conte »

balazsszekely

  • Guest
Re: The most easy encrypting/decrypting password method?
« Reply #49 on: October 02, 2021, 10:31:03 am »
I don't think it's related to language, must be something else. Do you have 32 or 64 bit Lazarus/FCP?

Conte

  • New Member
  • *
  • Posts: 27
Re: The most easy encrypting/decrypting password method?
« Reply #50 on: October 02, 2021, 10:34:57 am »
x86_64-win64-win32/win64.
That's what is wrote in the informazion window of lazarus. Not really clear.
I'm looking on google for a way to know exactly what it is.

Edit: it's 64 bit or the version for cross compiling.
« Last Edit: October 02, 2021, 10:44:14 am by Conte »

balazsszekely

  • Guest
Re: The most easy encrypting/decrypting password method?
« Reply #51 on: October 02, 2021, 10:42:43 am »
64 bit. Install a 32 bit version with fpcupdeluxe, it won't interfere with your current installation. Run a few test with the 32  bit version.

Conte

  • New Member
  • *
  • Posts: 27
Re: The most easy encrypting/decrypting password method?
« Reply #52 on: October 02, 2021, 11:32:10 am »
Yes, problem was lazarus bit version. With the 32bit works now.
So how do i decide if something must be compiled in 64 or 32 bit?

Also with this 32bit version the compiler take a lot of time to compile.

balazsszekely

  • Guest
Re: The most easy encrypting/decrypting password method?
« Reply #53 on: October 02, 2021, 11:58:05 am »
Quote
Yes, problem was lazarus bit version. With the 32bit works now.
Good!  Finally some progress...now we have to figure out why does not work with the 64 bit version. Again I'm not home now, but you can try the following:
in the 64 bit version replace {$mode objfpc}{$H+} with {$mode Delphi}. If does not work then you have to wait until Monday. Work with the 32 bit version for now.

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: The most easy encrypting/decrypting password method?
« Reply #54 on: October 02, 2021, 01:45:36 pm »
This is code that works on win32 and win64.

Code: Pascal  [Select][+][-]
  1. unit Unit1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6.  
  7. uses
  8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;
  9.  
  10. type
  11.   { TForm1 }
  12.   TForm1 = class(TForm)
  13.     Button1: TButton;
  14.     procedure Button1Click(Sender: TObject);
  15.   private
  16.   public
  17.   end;
  18.  
  19. var
  20.   Form1: TForm1;
  21.  
  22. implementation
  23.  
  24. {$R *.lfm}
  25.  
  26. uses
  27.   Windows;
  28.  
  29. const
  30.   Target: WideString = 'Conte''s super safe password until the first memory dump';
  31.  
  32.   CRED_TYPE_GENERIC          = 1;
  33.   CRED_PERSIST_LOCAL_MACHINE = 2;
  34.  
  35. type
  36.   CREDENTIAL_ATTRIBUTE = record
  37.     Keyword: LPTSTR;
  38.     Flags: DWORD;
  39.     ValueSize: DWORD;
  40.     Value: LPBYTE;
  41.   end;
  42.   PCREDENTIAL_ATTRIBUTE = ^CREDENTIAL_ATTRIBUTE;
  43.  
  44.   CREDENTIALW = record
  45.     Flags: DWORD;
  46.     Type_: DWORD;
  47.     TargetName: LPTSTR;
  48.     Comment: LPTSTR;
  49.     LastWritten: FILETIME;
  50.     CredentialBlobSize: DWORD;
  51.     CredentialBlob: LPBYTE;
  52.     Persist: DWORD;
  53.     AttributeCount: DWORD;
  54.     Attributes: PCREDENTIAL_ATTRIBUTE;
  55.     TargetAlias: LPTSTR;
  56.     UserName: LPTSTR;
  57.   end;
  58.   PCREDENTIALW = ^CREDENTIALW;
  59.  
  60. function CredWriteW(Credential: PCREDENTIALW; Flags: DWORD): Boolean; stdcall; external 'Advapi32.dll';
  61.  
  62. function CredWriteGenericCredentials(const Target, Username, Password: WideString): Boolean;
  63. var
  64.   Credentials: CREDENTIALW;
  65. begin
  66.   ZeroMemory(@Credentials, SizeOf(Credentials));
  67.   Credentials.TargetName := PChar(Target);
  68.   Credentials.Type_ := CRED_TYPE_GENERIC;
  69.   Credentials.UserName := PChar(Username);
  70.   Credentials.Persist := CRED_PERSIST_LOCAL_MACHINE;
  71.   Credentials.CredentialBlob := PByte(Password);
  72.   Credentials.CredentialBlobSize := 2*(Length(Password));
  73.   Result := CredWriteW(@Credentials, 0);
  74. end;
  75.  
  76. { TForm1 }
  77.  
  78. procedure TForm1.Button1Click(Sender: TObject);
  79. var
  80.   Username: WideString;
  81.   Password: WideString;
  82. begin
  83.   Username := 'conte';
  84.   Password := '12345';
  85.   if CredWriteGenericCredentials(Target, UserName, Password) then
  86.     ShowMessage('Successfully stored the password!')
  87.   else
  88.     ShowMessage('Crap!');
  89. end;
  90.  
  91. end.
  92.  

Conte

  • New Member
  • *
  • Posts: 27
Re: The most easy encrypting/decrypting password method?
« Reply #55 on: October 02, 2021, 03:40:00 pm »
Thanks everyone for helping me. GetMem said it is a crap security by the way. :D
We can take this topic open to look forward and find a safer auto login? Could be interesting for a lot of people imo.

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: The most easy encrypting/decrypting password method?
« Reply #56 on: October 02, 2021, 04:18:34 pm »
As I discussed at length in my earlier post: Link there is no secure way of archiving this.

I'm currently on my phone. Later when I'm at my desktop l can give you some more detailed explaination of different approaches ans their advantages

Conte

  • New Member
  • *
  • Posts: 27
Re: The most easy encrypting/decrypting password method?
« Reply #57 on: October 02, 2021, 04:25:29 pm »
@Warfley ok.
@DonAlfredo yes it works. Button1 only! I've left the same code for button2 and 3 and it gives error: unit1.pas(19,15) Error: Forward declaration not solved "Button2Click(TObject);"
The same with button3.

type

  { TForm1 }

    TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    Button3: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
    procedure Button3Click(Sender: TObject);   

Edit: it doesn't work anymore. I have just reopened the old project when it was working and it not work anymore. This time I think the problem is lazarus. I open a new project and it compile me the closed one. Is it a known bug?
I retried the same identical code of GetMem in the 32bit lazarus and the buttons do no actions.

Edit2: I had to delete the project folder. Re-create another project with the same code of the previous and it works. What was wrong with lazarus?
« Last Edit: October 02, 2021, 05:24:10 pm by Conte »

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: The most easy encrypting/decrypting password method?
« Reply #58 on: October 02, 2021, 08:07:54 pm »
As promised here is my more detailed explaination.

As already stated, just encrypting the password is basically just exchanging one password for another, which you then have the exact same problem of storing.
So the question is what do you want to protect against. Generally I see three levels of protection: 1. Protect against accedental access (e.g. accidentally delting, overriding or sharing the data), 2. protecting against accidentally finding or simple searches for the data (e.g. via filesystem scan), 3. protecting against unauthorized access.

The most simple solution that does not protect anything is to just write the data plain to a file in Documents, the users home folder or the program folder.
The first step of protection then is really simple, just store the data somewhere obscure like the AppData directory. Normally this directory is not visited by the user, so it is very unlikely that a user will accidentally delete, modify or share (e.g. by zipping all of the program folder and sending it to someone) the data.
The problem here is that if you simply do a filesystem search for the username, you will easiely find the file, or if someone finds a suspicious looking file and opens it can read it directly. To protect against that, simply encode your data. Encoding is changing the representation. For example, the text "Hello World" can be encoded as Base64 to read "SGVsbG8gV29ybGQ=". Decoding this isn't hard by any means, but no one will accidentally find your data and it protects against simple filesystem searches. This in combination with the first step (hidden directories) is what most applications like Browsers, FTP clients and co are using.

Lastly the protection against unauthorized users. This is done using password stores, such as the one provided by the Windows API. There are different levels of protection such can provide, but basically they all do the following: The passwords are stored by the password store encrypted with the users login credentials. When the user logs into the system with their account, the password store will be opend under that user. Applications can now request passwords from the password store. The password store verifies if the application is allowed to access the requested password (e.g. by checking if the user that started the application is also the same user who owns the password). Some password stores (I think the Windows one actually does this) make use of hardware modules provided by Intel and AMD CPUs which ensure that the system was booted under the correct circumstances, meaning if someone boots under a different OS (e.g. live Linux) these modules will not allow access to the password store.
This protects against a few different attacks. First you can only access passwords of a user that is currently logged in, and only by the user that stored the password, meaning another user (or someone who got hold of the HDD on a different machine) can not access the data. Some Implementations like on iOS or Android even make sure that only certain applications (i.e. applications by the same developer) can access shared data, meaning other applications even though the user is logged in can not access the data.
While all this filtering is neat and all, this isn't as secure as it sounds. Because systems can be hacked (e.g. iOS can be jailbroken) meaning all these neat checks if the requests come from authroized programs can be circumvented. The only real security it gives you is that as long as the user is not logged in (i.e. provided the password) you can not access the data. Or to put it differently, to get access to the data you need to have access to the users account and/or password. But if someone starts the PC and loggs in, there is no "hard" barrier between an attacker and the password anymore. That said, it is still massively more complicated than a normal approach.

To sum this up, the usage of a hidden folder only secures some stupid oopsies by the user like accidentally deleting the files. The encoding helps to secure against accidentally disocovering the password, e.g. if you have someone over and they get access to your PC with little time such that they don't stumble over your data by clicking the wrong things or using the filesystem search. The last one, the systems password store secures against people with hardware access to your device but not access to your system user.


So with that out of the way, what is right for you. Well generally speaking, it depends on two things, how valuable is the password and how likely is it that it will be attacked.
For example the password for my raspi is not very valuable as my raspi is just a mostly empty system lying somewhere in a drawer 99.9% of the time turned off. Accessing the Raspi also requires someone to break into my home making it rather unlikely that it will be attacked. This does not need a high level of protection.
My bank details on the other hand are highly valuable but if I only have them written on a piece of paper in my home, it is again rather unlikely someone will attack them. But if I store them in a password file on a cloud service or something similar, this changes and therefore require a high degree of security.

I would always make use of the first two measures (hidden folder, encoded data), as this is basically free (doesn't take much effort, easiely portable). This is what for examples browsers like Firefox or Chrome use to store the Passwords. Whats secure enough for these applications is probably secure enough for your application as well.
The password store is only required on multi user systems where you need to protect against other users on that system (e.g. in a corporate setting, where PCs are shared e.g. by using a Windows Domain Server) or, if you fear that someone will break into your home, steal your PCs hard drive just to get to that password.
If your data is so valuable that people would break into your home just to get it, then I would suggest to not store that password at all and have the user enter it every time. Users should be expected to take these 10 seconds to enter the password if the data is so valuable.

Conte

  • New Member
  • *
  • Posts: 27
Re: The most easy encrypting/decrypting password method?
« Reply #59 on: October 02, 2021, 11:15:59 pm »
@Warfley thank you!

 

TinyPortal © 2005-2018