Security - How freaky can you get!

[David Heffernan 2345]

Stepping back here, are piecemeal comments from numerous different authors in a forum the best way to design the security for your software?

 

I'd want to be reading a book written with a train of thought. Covering a variety of issues, with explanation of why they matter. And a book that has been well reviewed. 

 

It seems to me that standalone tips are the kind of thing that lead to insecure software. Security is an end to end, entire process thing, where the interactions matter. Using a couple parts of best practise doesn't make your software secure. It only needs one part to be missing. 

[Fr0sT.Brutal 900]

On 1/4/2021 at 7:10 PM, Clément said:

By the end of 2020 I was surprised by a new customer who said he didn't want a "Delphi software", because Delphi was unsafe for his business. His software got hacked.
Since that was a first, I got more information about what happened and what that security breach was all about.

 

The hacker discovered the manager's password by tampering the application executable. I don't know what tool was used, but all password editors were showing the actual password instead of '*'.
Not only in editors, but in grids too. The application had a feature that requested a manager password to allow changes in some fields. That screen was gone! Any employee could modify, delete, or include data without restrictions. Even some restricted data were display for everyone.

1 - When using WinAPI editors (and Delphi VCL editors are WinAPI wrappers) for bulleting passwords, single SendMessage is enough to reveal them (at least it was in WinXP).

2 - Storing a password in memory in readable form makes it elementary to grab it by reading process' memory

3 - Signing a binary won't protect from #1 & #2 at all

4 - Just including protection library won't do any reasonable protection. Protection must be wisely integrated in the code level.

[David Heffernan 2345]

2 minutes ago, Fr0sT.Brutal said:

1 - When using WinAPI editors (and Delphi VCL editors are WinAPI wrappers) for bulleting passwords, single SendMessage is enough to reveal them (at least it was in WinXP).

If you've managed to be able to execute code on the target's machine, it's already game over. Bulleting passwords is only ever intended to stop over the shoulder password theft.

 

4 minutes ago, Fr0sT.Brutal said:

2 - Storing a password in memory in readable form makes it elementary to grab it by reading process' memory

See point 1.

 

4 minutes ago, Fr0sT.Brutal said:

3 - Signing a binary won't protect from #1 & #2 at all

No matter since points 1 and 2 are invalid.

[Fr0sT.Brutal 900]

2 minutes ago, David Heffernan said:

If you've managed to be able to execute code on the target's machine, it's already game over

Well, you're like "If a thief is managed to get into your house, it's already game over". But that's not true and "Home alone" proves it earnestly 🙂

Jokes aside, different cases require different measures. Your sentence asserts that any kind of software running on machines which limited users could access is a priori will be hacked. I don't think so.

[David Heffernan 2345]

12 minutes ago, Fr0sT.Brutal said:

Your sentence asserts that any kind of software running on machines which limited users could access is a priori will be hacked. I don't think so.

That's not what I am saying. I'm saying that if an attacker gets as far as running code on your machine, then things like reading another process's memory are moot. Once the attacker is executing their code on your system, it's over.

[Fr0sT.Brutal 900]

17 minutes ago, David Heffernan said:

That's not what I am saying. I'm saying that if an attacker gets as far as running code on your machine, then things like reading another process's memory are moot. Once the attacker is executing their code on your system, it's over.

Okay. Presume there is Windows-10 PC and you can run any code with guest rights. Tell me how to read the memory of any system service 😉

[Marat1961 17]

After one of the releases of our program was hacked about 15 years ago and posted the hacked version on FTP.
We protect our code with a protector.

 

I think our company uses Enigma now.

There have been no more such hacks since then.

 

At least the code must be digitally signed and its integrity must be verified.

 

If something goes wrong, we check some flags somewhere and 
the program changes its behavior (works incorrectly). 
It may crash after a while, modal windows stop working well, etc.

 

Separate out the fact of tamper detection and where things will work differently should be placed as far as possible in time and scattered across the code.

Edited January 15, 2021 by Marat1961