Security - How freaky can you get!

[FPiette 382]

1 hour ago, shineworld said:

Where possible I use Sentinel HASP Keys and related software protections.

There are emulators for such devices. https://www.google.com/search?q=Sentinel+HASP+cracked

[shineworld 73]

45 minutes ago, FPiette said:

There are emulators for such devices. https://www.google.com/search?q=Sentinel+HASP+cracked

Oh, world.... I don't know about that...
I'm a little bit angrier now.
The HASP keys aren't cheap at all (we spend more than $50 each dongle)...

 

90% of our software is freeware because made for specific hardware to work (we sell hardware, not software).
But 10% (customer-specific programs) use HASP dongle to recover a minimal part of development costs...

Edited January 7, 2021 by shineworld

[David Heffernan 2345]

2 hours ago, shineworld said:

Oh, world.... I don't know about that...
I'm a little bit angrier now.
The HASP keys aren't cheap at all (we spend more than $50 each dongle)...

All of these security hardware devices are crackable. HASP has a terrible record. And the prices they charge are just ludicrous. 

 

You should view these things as a means to help your paying customers use the right amount of licences. They are not going to help you stop hackers cracking your program. 

Edited January 7, 2021 by David Heffernan

[Anders Melander 1782]

1 hour ago, David Heffernan said:

They are going to help you stock hackers cracking your program. 

Good one

[mvanrijnen 123]

I'v (very long ago), published shareware, with (don't know which anymore) protection component (bought a component back then).

1 Day after publising the cracks where available on the internet 🙂
 

(and this was a niche product, some tooling for Progress 4GL, but created with delphi)

Seems some crackers do things completely automaticly.

 

[FPiette 382]

13 minutes ago, mvanrijnen said:

I'v (very long ago), published shareware, with (don't know which anymore) protection component (bought a component back then).

1 Day after publising the cracks where available on the internet

I bet that hackers have ready procedure to crack anything using some "standard" library. You'd better design your own specific code instead of buying some existing library/dongle/whatever that the hacker can buy an experiment with his own programs and build a tool to crack that.

 

There are hackers that do that just for the fun!

 

[David Heffernan 2345]

36 minutes ago, FPiette said:

I bet that hackers have ready procedure to crack anything using some "standard" library. You'd better design your own specific code instead of buying some existing library/dongle/whatever that the hacker can buy an experiment with his own programs and build a tool to crack that.

 

There are hackers that do that just for the fun!

 

This won't work either. 

[FPiette 382]

1 hour ago, David Heffernan said:

This won't work either. 

What do you mean?

[David Heffernan 2345]

7 minutes ago, FPiette said:

What do you mean?

If somebody wants to crack your program then your home brew protection won't hold up either. 

[FPiette 382]

4 minutes ago, David Heffernan said:

If somebody wants to crack your program then your home brew protection won't hold up either. 

Sure, by definition.

My point was that using an existing  library to protect a software will just help the hackers and reduce the time between the software publication and the cracked version. When properly designing a protection mechanism will slow down the hackers but absolutely no system could stop the expert hacker.

[David Heffernan 2345]

And my point is that you are giving yourself a false sense of security. It will take you extra time to develop your own licensing system, and then it gets cracked anyway. You may as well use a standard off the shelf tool and save yourself the time. Plus your paying users are able to use a system that they are familiar with for other software. 

[Guest]

6 hours ago, shineworld said:

- Reduce the amount of UI used in DFM (sometimes I prefer to create UI with code).

No... specifically audit/monitor (by SVN or such) your dfm's to make certain that no component stored ANY sensitive/test info in a property.

The decision design-time vs runtime should be begotten in completely different contexts.

[Clément 148]

 

There are some tricks we might use in our app to help slowing down an eventual attacker. But given the fact that even windows get hacked... not much hope in that area.
Anyway, I would like to ask if there's something we can do regarding REST. More specifically the HTTP header.
This is just an example to help illustrate the problem:
 

POST /api/2.2/auth/signin HTTP/1.1
HOST: my-server
Content-Type:application/json

Protecting the first line is my objective.
Would it make any sense to protect it?
For example:
 

POST /api/Mi4yL3RoaXN3b3VsZGJlcHJvdGVjdGVkd2l0aEhNQUMyNTYvZm9yZXhhbXBsZQ== HTTP1.1
HOST: my-server
Content-Type:application/json

Is there anything we can do about this, or just leave it opened?
The application will communicate only with this particular WebServer. I don't have to worry with other WebServers (apache or IIS for example)
 

 

 

[FPiette 382]

1 hour ago, Clément said:

ask if there's something we can do regarding REST.

Use HTTPS with certificates.

[Guest]

1 hour ago, Clément said:

POST /api/Mi4yL3RoaXN3b3VsZGJlcHJvdGVjdGVkd2l0aEhNQUMyNTYvZm9yZXhhbXBsZQ== HTTP1.1
HOST: my-server
Content-Type:application/json

Is there anything we can do about this, or just leave it opened?

For this particular case, i would suggest a behaviour like the one with RTC SDK, 

You are using base64 to encode the URI, but you could do better using PKI and encrypt it with pre shared public key, where the server only have the private and can decode them, so client will encode with public key then encode again in Base64 or even better i would suggest use Base64URL (a little modified but standardized version) to use in the request path, just remember to use nonce as useless additional parameter (random value, a simple counter, current time..etc) to make sure the encryption will generate different results in the final encoded URI while the content will still the same for each request even if it is the same URI.

[Clément 148]

3 hours ago, FPiette said:

Use HTTPS with certificates.

I will use HTTPs with certificate, but tools like fiddler can bypass HTTPS, and I believe a company with a proxy setting could easily be hacked.
I do believe this is way over my grade of concern, but since the first line is plain text, it would be nice to add some more slow downs.
Ex: I don't want to receive thousands "token requests"..

Edited January 9, 2021 by Clément

[Clément 148]

2 hours ago, Kas Ob. said:

For this particular case, i would suggest a behaviour like the one with RTC SDK, 

You are using base64 to encode the URI, but you could do better using PKI and encrypt it with pre shared public key, where the server only have the private and can decode them, so client will encode with public key then encode again in Base64 or even better i would suggest use Base64URL (a little modified but standardized version) to use in the request path, just remember to use nonce as useless additional parameter (random value, a simple counter, current time..etc) to make sure the encryption will generate different results in the final encoded URI while the content will still the same for each request even if it is the same URI.

I did some testing, and the largest URL encrypted with pre shared key and encoded base64URL reaches 600 chars.. It's recommended to keep URL under 2000 chars.
This might do the trick!
Thanks

[Guest]

1 minute ago, Clément said:

I did some testing, and the largest URL encrypted with pre shared key and encoded base64URL reaches 600 chars.. It's recommended to keep URL under 2000 chars.
This might do the trick!

Still there is shorter approach, by shorter i mean you could reach 1 to 1 length in the URL (base64 length) or worst case scenario you will have the minimum length with multiplication of the block size of the used symmetric algorithm. 

 

how to do that ?

many ways but here i will list two you might like

1) Client will have his own PKI pair and send his public once as http header value and the server will lock/associate his public key just like a cookies, this can be done once or for each request, also here ECDH or any Diffie–Hellman algorithm will do, the benefit will the size of URI will be considerably shorter and faster, also the URI will be encrypted by symmetric algo, like AES ..

2) You don't need to change PKI you just tested, just encrypt the symmetric key itself ( the client choose randomly a key ), and send it as HTTP value as mentioned above, as long the server is keep tracking of the HTTP session then all consequence URI requests can be encrypted by symm.. this is the shortest and fastest approach.

[FPiette 382]

12 hours ago, Clément said:

15 hours ago, FPiette said:

Use HTTPS with certificates.

I will use HTTPs with certificate, but tools like fiddler can bypass HTTPS,

When Fiddler intercept and decrypt HTTPS, It re-singing traffic with a self-signed certificate and that can be detected at each end of the connection.

Edited January 10, 2021 by FPiette

[Guest]

42 minutes ago, FPiette said:

When Fiddler intercept and decrypt HTTPS, It re-singing traffic with a self-signed certificate and that can be detected at each end of the connection.

It is impossible for a server to detect middle man when the secure connection is TLS/HTTPS with only server side certificate authentication, the only way is to have client side certificate along the server side which is very rare practice and hard to deploy.

It can be detected from client side but this will return us to first step, how to trust OS store only.

 

Also many AV software does that out of the box with default settings, install self signed certificate in OS root trust store and by doing so they can decrypt all the traffic that depends on the OS trust store, take an example Kaspersky even in trail version will intercept all the HTTPS traffic by default settings (and many other TLS connection) while Chrome running on the same device will not complain about the certificate but will show it as trusted and valid, you can check it and will see it is issued by Kasperkey, also here it is impossible for server to know if the connection been intercepted and handled, even if Chrome (HTTP client) went ahead and used HPKP, it is most easy process for Kaspersky to adjust the pinned key on the fly.

 

There is also one way for the client to make sure the connection is secure and that by utilizing DNS, either DANE or CAA, DANE is not popular and will not be, that leave us with CAA https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization

Such way the client can establish an additional trust chain that should match the server certificate, which is hard for Fiddler or any AV to replicate, but again AV can intercept DNS calls and change them on the fly, this can be solved by using DNSSEC and validate the keys up to the root key, https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions and this complicated the whole thing way too much, so i really do see Clement point, and why he does want to depend on certificate pinning on the client to skip the whole OS trust store thing.

[Angus Robertson 574]

Quote

It is impossible for a server to detect middle man when the secure connection is TLS/HTTPS with only server side certificate authentication

Which is why many servers insist on using JOSE technologies such as Json Web Signing which means the headers are signed with a password or private key before being sent, so can not be changed without the server knowing, this is how Let's Emcrypt and OAuth1/2 work.  Or Json Web Encryption if you don't want the headers read. 

 

Angus

 

[Guest]

7 minutes ago, Angus Robertson said:

this is how Let's Emcrypt and OAuth1/2 work

I think both will not help Clement here, because both can guarantee authenticity but not privacy, while he was after privacy of the content even for the URI, though i might be wrong.

[Angus Robertson 574]

The original example was a short POST URL with parameters sent as Json, which can easily be encypted in numerous ways for privavy, base64 does not protect anything.  Advantage of using JOSE is the use of standard libraries.  Not sure why one would want to prorect a simple login page URL. 

 

Angus

 

 

[Clément 148]

From what I can tell, usually the first requests are most "dangerous". For example, you can hash a password, all a hacker have to do is use that same hash. If he knows where to send it, you got a problem.
But if I can hide the URL of the "firsts" connections it will make harder for a hacker to identity what the protection schema is, and buy us some time until he is figures out what he is dealing with.
My WebServer is already using JWT with AES encryption.  After the initial requests it will get harder to hack.  I'm considering using also encrypted URL for all the other requests. But still, something to look forward to.

 

Another trick I'm using to gain time ( I guess it's safe to comment here )  : I'm going "hacker fishing" .

Some of you may remember I fell victim of a nasty ransomware a few months ago. I was able to recover everything.
I've being drinking coffee over this and what caught my attention was the time spend to encrypt my HUGE glyph image library. The security factor here is HUGE and TIME.
The more time hacker spend hacking, the more time we gain to react! ( I know, I know, I'm a modest genius   )

I googled  RFCs for anything I could use, and this is what I came up with:
  1 - Some ports are bound to some specific protocols, and some protocols have initial banners.
  2 - Some ports are bound to some specific functions, or remote operations, like directory listings and or file downloads.
  3 - Brute force attack usually try to find opened ports, but still, they search for ports in a certain order.
  4 - Most of firewalls shut ports closed. This will help them scanning all the range port set looking for a breach. There are tons of code in google helping them scan for opened ports in seconds!

 

But what would happened if some ports are intentionally opened with "fake server" listening to them? And why not "add more security" with a nice user/password: admin/1234 ?
For 1: there's nothing on RFC that limits the size of a Banner. The server is generating a 20TB banner for our unwanted guest.
If he stores the banner it will create a disk space problem, or at least, this would slow down his attack until the whole banner is downloaded.

For 2: the server generates over a million files to download. Had any of you try to use Windows Explorer with a folder with over a millions of files?
Again, it will slowdown the attack.

 

And while the fake server is keeping our unwanted guess busy, it is also including their IPs addresses to the firewall black list ...

 

 

Edited January 10, 2021 by Clément

[FPiette 382]

14 hours ago, Clément said:

From what I can tell, usually the first requests are most "dangerous". For example, you can hash a password, all a hacker have to do is use that same hash. If he knows where to send it, you got a problem.

To avoid reusable hash, one could to use the "challenge" protocol:

1) The client send a request to the server to get a "challenge" (For example a random string).

2) The client send a 2nd request having the password combined with challenge hashed together

3) The server check the hash he received from the client by comparing it with the hash he has computed using the know password, the known challenge and known way to combine them.

4) The server when creating a challenge give it a very short live time and cancel it when the hash is received.

 

With that two steps procedure, the hacker capturing traffic can grab the challenge and the hash. The hash is usable only once and won't help for future connections. The hacker has to do reverse engineering either the client or the server to discover how the challenge and password are combined before computing the hash, an discover which kind of hash has been used. This reverse engineering requires to have access to the computer to get a copy of the software. Should be must more complex than "simply" capturing traffic with a sniffer.