15 posts in this topic

IanN1990 10

It is IMPOSSIBLE to keep information safe from someone who is dedicated to getting it and the only tool is causing it more effort then it is worth.

Hashing a password in itself means nothing, as if an attacker has a table of every hashed word (rainbowtable) it is as simple as "copy hash & Ctrl + F".

That's why we add a salt. So now an attacker must have a table made with every word + salt, this means he needs to know the algorithm of where the salt goes and what the salt is.

Assuming he has access to this information, it doesn't make how clever the algorithm is because a new table could be generated. The salt also needs to be unique for each person.

This does not protect it verse Brute forcing. As you may think a 7 digit combination with a 5 digit salt = 1,000,000,000,000 combinations (excluding where the salt could go) but when most good gaming PCs could perform 17042497.3 guesses per second that "could" less then 20 hours to brute force (assuming they got it on the absolutely last guess). Scary right!!

This leaves one last tool in the trade (from what i can see) called key-stretching. This is where, the process to generate a key would take at lest (x) second. So that brute force above turns from 17042497.3 guesses per second to 17042.4973 (assuming my maths is right) and now you are looking at 679 days with a key stretch delay of 1 second.

The two big programs regarding this are PBKDF2 and bcrypt (despite my searching on the forum nether are supported within auto it and / or free to commercial use)

So this in mind, is this a correct implementation and understand of key stretching

As the finial hash, would of only been obtained by hashing. the password 9999 times.

This takes 5.41 seconds vs 0.07196 making it take 750% longer to brute force. Taking 1 day in 75 and 1 year into 75.

This also goes into the idea of, by the time they get this information would that information useful. Even if they did find out the name of your super-top secret bank account, 75 years down the line would that bank even be around?

Share this post

Link to post

Share on other sites

AutoBert 159

The problem is not the hash, the problem is AutoIt is a scripting language and very easy reversed to source. After having source, just eliminating the check if password ist true is all what must be done and protected code can be excecuted.

Share this post

Link to post

Share on other sites

water 1,427

I would separate the GUI for first level from the execution of the commands (altering AD etc.).
Create a virtual machine with a service account with all the needed permissions (stripped down as far as possible), do not allow interactive logon for this account.

The GUI part would send a command to the virtual service machine to be executed, the service machine validates it (is command OK, is sender allowed etc.) and if OK executes and logs the command as well as the result.

Share this post

Link to post

Share on other sites

IanN1990 10

I would separate the GUI for first level from the execution of the commands (altering AD etc.).
Create a virtual machine with a service account with all the needed permissions (stripped down as far as possible), do not allow interactive logon for this account.

The GUI part would send a command to the virtual service machine to be executed, the service machine validates it (is command OK, is sender allowed etc.) and if OK executes and logs the command as well as the result.

That's the way our service tool works here.

i suspect your referring one of my older question about storing passwords inside scripts. I took your advice and dropped that idea, opting for the same thing you suggested.

In this question however i am just generally learning about key stretching with autoit To find out if it is even possible

Share this post

Link to post

Share on other sites

water 1,427

Post #2 provides the final answer.
This has been discussed many, many times on the forum - the answer was always the same.
Youd can't securely store a password in AutoIt nor call an internal security function because a malicious user could decrypt the password or remove the security function in just a few minutes.

Share this post

Link to post

Share on other sites

IanN1990 10

In this example, the autoit code would be stored in a part of windows that users permissions wouldn't have access to and task scheduler (set using the admin account) is what would run the program

1. This prevents them accessing the source exe and for the most their own stored hash (which is only a check)

The tool does nothing important, it only adds a layer of security when they have none. So even if someone is clever enough to "for this example" install something to read and understand the program from memory and or edit it from memory it wouldn't mater

All i want to know is, does my example demonstrate a good example of key stretching or is my understanding of key stretching wrong?

*Though, in different circumstances, i do fully take on both of your points