Password Hash & Verification - Easy & Lightweight

This is a terrible idea for multiple reasons.
- The most obvious one is that it's slow, it uses http which has latency compared to pure implementations.

local post = http.post("http://api.twijnweb.com/password/hash","pass="..pass)

- You are sending passwords via an unsecured http connection to your server which may or may not log every request made to it, including passwords.
- Pure implementations of multiple hash functions are doable and decently fast in CC (md5, sha1, blake256, sha256)

Anavrins, on 30 December 2016 - 06:32 PM said:

This is a terrible idea for multiple reasons.
- The most obvious one is that it's slow, it uses http which has latency compared to pure implementations.

local post = http.post("http://api.twijnweb.com/password/hash","pass="..pass)

- You are sending passwords via an unsecured http connection to your server which may or may not log every request made to it, including passwords.
- Pure implementations of multiple hash functions are doable and decently fast in CC (md5, sha1, blake256, sha256)

It's http since CC supports few certificates. The api subdomain does not allow for secured connections, however www. and nothing does provide it (ie. https://twijnweb.com). Anyway, these requests are technically anonymous - the chances of being on a server with someone using this API and being able to get to the computer to crack the code is literally impossible. I can easily send requests with little to no noticeable latency, any my internet is plainly terrible, with a expected speed of 6 Mbps up, .5 down, however often get to as low as .3 up and down with a ping of 1000+, since my ISP claims we are "too far away." Programs on ComputerCraft have a decent issue, and that is that all algorithms etc. are public. This in some situations can make a password easier to crack. The hash generated by the server is decently hard to crack. You can decide if you want to take my word that I am not logging any of the passwords sent to it. I very well could. Just tie it up to a SQL database, and yay… I have tons of passwords that people have used! What next… test the passwords on literally every account possible on every server possible, on every webserver, just to hope some person has used that password? It's quite not worth it. Both of them purely check the input with the algorithms and see if they are equivalent, echoing back the result to the person who requested the page. (also known as you)


The conclusion is: This program will suffice. ComputerCraft plainly was not made to be a secure programming language. This is quite honestly the best you can get when it comes to security for CC, and if you think that other ways are better, that may be so, however I'm fairly certain it's not more secure. I built this to be lightweight on a CC computer, and I believe it has successfully achieved this, although I do understand the flaws that you pointed out.

Some flaws in your logic I would like to point out:
1) there will always be latency when using the http API. It also doesn't depend on the users connection, but the connection of the server the user is playing on ( which might be local though). Also, it is possible that the http whitelist is enabled or http is disabled completely.

2) obscurity /= security. Just because people don't know how something is encrypted won't make is more secure. Rot16 is Rot16. Even if you claim that it is a custom algorithm which is more secure than RSA (in your opinion). In addition to that there is no practical way of reversing a hash, even though you know the code which generated it. That's not how hashes work. You are better off searching for collisions.

3) ComputerCraft is not a programming language, but a mod for Minecraft which utilizes Lua ( which is a programming language).

4) languages can't be more secure than others. It all depends on the algorithms used, which are language independent.

5) even though this code is "okay" for most use cases inside of CC, it just implies way too many security risks outside of it. Examples for this are: the server owner is running a proxy, collection all the data sent; the http API has been modified that it logs every request.6) just because your main domain supports HTTPS won't make the subdomain more secure. It is just http.

H4X0RZ, on 31 December 2016 - 01:04 AM said:

Some flaws in your logic I would like to point out:
1) there will always be latency when using the http API. It also doesn't depend on the users connection, but the connection of the server the user is playing on ( which might be local though). Also, it is possible that the http whitelist is enabled or http is disabled completely.

2) obscurity /= security. Just because people don't know how something is encrypted won't make is more secure. Rot16 is Rot16. Even if you claim that it is a custom algorithm which is more secure than RSA (in your opinion). In addition to that there is no practical way of reversing a hash, even though you know the code which generated it. That's not how hashes work. You are better off searching for collisions.

3) ComputerCraft is not a programming language, but a mod for Minecraft which utilizes Lua ( which is a programming language).

4) languages can't be more secure than others. It all depends on the algorithms used, which are language independent.

5) even though this code is "okay" for most use cases inside of CC, it just implies way too many security risks outside of it. Examples for this are: the server owner is running a proxy, collection all the data sent; the http API has been modified that it logs every request.6) just because your main domain supports HTTPS won't make the subdomain more secure. It is just http.

1) That is my mistake. I meant to say that this resulted into little to no noticeable latency. There will always be latency.

2) Fair enough. I will say though that this is NOT a custom algorithm.

3) I don't take this as a flaw with my logic, but I was referring to the always open source nature that CC has, which is not good in all cases.

4) Same as above

5) There really is no way to prove that I'm not, but I can prove that there is no point to. Say that someone inserted "password" to get hashed. Now having that password is fine and wonderful, but I can't do anything further than that. I don't know where the password came from, if the password was used anywhere else, or anything. I might as well just use a list of common passwords and iterating througha member list, looking for every possible combination hoping for one that'll match. (Which many sites protect against now)

6) I could very well move the folder to http://twijnweb.com/api instead of using the subdomain, allowing for a secured connection. The problem I was pointing out was that ComputerCraft only accepts certain certificates from websites, and mine is not included in that in my tests, and therefore returns nil.

_oldhash = password.hash
function password.hash(text,type)
upld = http.post(somewhere to upload it)
upld.close()
_oldhash(text,type)
end

TheRockettek, on 31 December 2016 - 07:40 AM said:

_oldhash = password.hash
function password.hash(text,type)
upld = http.post(somewhere to upload it)
upld.close()
_oldhash(text,type)
end

You can't protect against that. Any program could potentially have that problem. Again, it's showing that CC code is not particularly secure.

The point is, how can you prove this is less secure than this website.

This website uses an HTTP connection. So does mine. Mine has the ability to use an https connection, yet CC does not support it. This website COULD be storing your password in a non-hashed way. (Not saying it does) You can view your own password hash by pressing the (i) in the corner (on chrome), opening up the cookies, looking under www.computercraft.info, and it shows your member_id and pass_hash. This isn't particularly insecure, however an attacker could imitate the password and potentially access your account.

The security issues you've presented, at least from my perspective, are not my server's or my programs fault. They are the fault of CC's plain insecurity, which every password hashing program will have. I claimed this program was "secure" above, but maybe I should reword that - It's secure under ComputerCraft standards. The only thing that makes this less secure than any of the provided programs is that it uses an HTTP connection to gather the hash and verify anonymously.

You just have to redefine your standards of security in CC.
Assuming somebody haven't compromised your computer that was password protected, then nobody could override that function to send the password somewhere else.
Compared with http, even with an uncompromised computer, you have much more vector for leakages, server owner sniffing outbound traffic, no-https because of outdated Java and password most likely appearing in your server logs.
You may not be logging anything, but that's not how you do security, you don't trust a random forum user with your password for any reasons.

Anavrins, on 31 December 2016 - 06:10 PM said:

You just have to redefine your standards of security in CC.
Assuming somebody haven't compromised your computer that was password protected, then nobody could override that function to send the password somewhere else.
Compared with http, even with an uncompromised computer, you have much more vector for leakages, server owner sniffing outbound traffic, no-https because of outdated Java and password most likely appearing in your server logs.
You may not be logging anything, but that's not how you do security, you don't trust a random forum user with your password for any reasons.

Fair enough.

However it is not recommended to use the same password for different sites anyway. If you say you've put the same password into a computercraft computer as you did to a website, that's not a particularly good idea, no matter what protection they have used.

But it's also recommended to have as few 3rd party services access the password as that reduces the amount of possible leaks. Although off-loading the load onto a separate "normal" server isn't a bad idea in itself, it certainly isn't a good one security wise because the hashing performance of CC is good enough to render the usage of 3rd party stuff useless/not recommended.