Jump to content




[V4.1 COMING!] LoganDark's Password Lock

computer turtle pocket

115 replies to this topic

#41 LDDestroier

  • Members
  • 1,095 posts
  • LocationACDC Town

Posted 06 April 2016 - 01:27 AM

View PostLoganDark, on 05 April 2016 - 09:59 PM, said:

I get that, but the problem is if you're not making it yourself you can't find a good lock. Basically, if you search for one that just looks good, you'll find one that does NOT block termination and stores the password in plaintext. If you search for one with security, you will find mine ( :P). I'm trying to focus on security while not distracting the user with all this prettyness.

How dare you sir. My fine door lock hashes pretty well (not SHA256, but well) AND has excellent graphical design. It has termination protection, and, if you put in door sides to an array, it turns into a door lock.

#42 LoganDark

  • Members
  • 231 posts
  • LocationMacintosh HD/Users/LoganDark

Posted 10 April 2016 - 02:37 AM

View PostLDDestroier, on 06 April 2016 - 01:27 AM, said:

...My fine door lock...
...and, if you put in door sides to an array, it turns into a door lock...
So your door lock turns into a door lock? How interesting.

You failed. :P

#43 LDDestroier

  • Members
  • 1,095 posts
  • LocationACDC Town

Posted 10 April 2016 - 04:22 AM

Nooooo! Typing mistakes! My only weakness!

...I meant it's a computer lock that also works as a door lock.

#44 LoganDark

  • Members
  • 231 posts
  • LocationMacintosh HD/Users/LoganDark

Posted 10 April 2016 - 04:46 AM

View PostLDDestroier, on 10 April 2016 - 04:22 AM, said:

Nooooo! [snip]
Isn't that supposed to have 4 o's only? :P

#45 LDDestroier

  • Members
  • 1,095 posts
  • LocationACDC Town

Posted 10 April 2016 - 04:21 PM

View PostLoganDark, on 10 April 2016 - 04:46 AM, said:

View PostLDDestroier, on 10 April 2016 - 04:22 AM, said:

Nooooo! [snip]
Isn't that supposed to have 4 o's only? :P

NOOOOOOOOOO!!!

#46 LoganDark

  • Members
  • 231 posts
  • LocationMacintosh HD/Users/LoganDark

Posted 10 April 2016 - 09:44 PM

View PostLDDestroier, on 10 April 2016 - 04:21 PM, said:

View PostLoganDark, on 10 April 2016 - 04:46 AM, said:

View PostLDDestroier, on 10 April 2016 - 04:22 AM, said:

Nooooo! [snip]
Isn't that supposed to have 4 o's only? :P

NOOOOOOOOOO!!!

It's supposed to have 15 O's, not 10. :P :P :P

#47 LoganDark

  • Members
  • 231 posts
  • LocationMacintosh HD/Users/LoganDark

Posted 25 April 2016 - 05:13 PM

View PostmoTechPlz, on 21 March 2016 - 03:56 PM, said:

Hi, about the sleep thing, you could do both. Use a timer to wait 2 or 3 seconds or skip when the 'anykey' is pressed.

I have an idea on how to do that, but I'm not quite sure about it. Can you provide an example?

Edit: post not needed

Edited by LoganDark, 25 April 2016 - 05:14 PM.


#48 Luca_S

  • Members
  • 407 posts
  • LocationGermany

Posted 25 April 2016 - 05:46 PM

It's secure, but you are wasting resources, there's no need in hashing 50 times. In this case it only makes it slower, but it is still secure, but there might be cases(easy example: ROT-13) where encrypting/hashing it more often makes it insecure:

Plaintext: Hello
Encrypted 1: Uryyb
Encrypted 2: Hello

#49 Anavrins

  • Members
  • 775 posts

Posted 25 April 2016 - 06:54 PM

This happens with every stream cipher, RC4, Chacha20, AES-CTR, but not hashes.
The problem with multiple hashing is that it doesn't change the odds of finding a collisions or make it more secure, it only makes it slow, which I think is just what Logan wanted out of it.
Although his implementation is pretty much equivalent to hashing the password with a huge salt, which is kind of wasteful.
Something similar to pbkdf2, would be the best here, since you can fine tune how slow you want it to run, without the need of 50 different salts.

I might give implementing pbkdf2 a shot later today.
Bcrypt would require implementing Blowfish in CC, which I can't be arsed to do, while pbkdf2 only requires hmac.

Edited by Anavrins, 25 April 2016 - 06:59 PM.


#50 LoganDark

  • Members
  • 231 posts
  • LocationMacintosh HD/Users/LoganDark

Posted 25 April 2016 - 07:00 PM

View PostAnavrins, on 25 April 2016 - 06:54 PM, said:

This happens with every stream cipher, RC4, Chacha20, AES-CTR, but not hashes.
The problem with multiple hashing is that it doesn't change the odds of finding a collisions or make it more secure, it only makes it slow, which I think is just what Logan wanted out of it.
Although his implementation is pretty much equivalent to hashing the password with a huge salt, which is kind of wasteful.
Something similar to pbkdf2, would be the best here, since you can fine tune how slow you want it to run, without the need of 50 different salts.

I might give implementing pbkdf2 a shot later today.

I wanted it slow, but also secure. Hashing with 50 different salts is very secure, possibly even unbreakable without the help of the salts which are stored conveniently in the file for all to use lol.

Note: Non-malicious modifications to my system are now allowed. Anavrins, do what you please with the algorithm. :P

#51 Luca_S

  • Members
  • 407 posts
  • LocationGermany

Posted 25 April 2016 - 07:04 PM

View PostLoganDark, on 25 April 2016 - 06:57 PM, said:

View PostAnavrins, on 25 April 2016 - 06:54 PM, said:

-snip-

I wanted it slow, but also secure. Hashing with 50 different salts is very secure, possibly even unbreakable without the help of the salts which are stored conveniently in the file for all to use lol.
Hashing only 1 time with salt is already secure. And yeah, it gets more secure if it's slower, but if you consider the fact that it's already secure after hashing it 1 time for me it's a resource and time waste.

View PostAnavrins, on 25 April 2016 - 06:54 PM, said:

This happens with every stream cipher, RC4, Chacha20, AES-CTR, but not hashes.
-snip-
As I said it doesn't effect hashing, but in some cases it might make it more insecure

#52 Anavrins

  • Members
  • 775 posts

Posted 25 April 2016 - 07:05 PM

View PostLoganDark, on 25 April 2016 - 06:57 PM, said:

I wanted it slow, but also secure. Hashing with 50 different salts is very secure, possibly even unbreakable without the help of the salts which are stored conveniently in the file for all to use lol.
Well, it's slow, which is a good thing, but not more secure, this construction is as strong as the inner most hash iteration in the loop.
Granted, it's probably never going to be cracked, but stating it's more secure is false, and because of that, having 50 salts is redundant and a of waste space.

Edited by Anavrins, 25 April 2016 - 07:07 PM.


#53 LoganDark

  • Members
  • 231 posts
  • LocationMacintosh HD/Users/LoganDark

Posted 25 April 2016 - 07:29 PM

View PostAnavrins, on 25 April 2016 - 07:05 PM, said:

View PostLoganDark, on 25 April 2016 - 06:57 PM, said:

I wanted it slow, but also secure. Hashing with 50 different salts is very secure, possibly even unbreakable without the help of the salts which are stored conveniently in the file for all to use lol.
Well, it's slow, which is a good thing, but not more secure, this construction is as strong as the inner most hash iteration in the loop.
Granted, it's probably never going to be cracked, but stating it's more secure is false, and because of that, having 50 salts is redundant and a of waste space.

Sure, it's not that more secure, but it's more secure nonetheless. Argument or not, it is, but it's not an improvement as much as from plaintext to 1 hash.

#54 LDDestroier

  • Members
  • 1,095 posts
  • LocationACDC Town

Posted 25 April 2016 - 07:32 PM

If you'd sacrifice speed and convenience for an insignificant security boost, at least have a config option to make it hash once.

#55 Luca_S

  • Members
  • 407 posts
  • LocationGermany

Posted 25 April 2016 - 07:32 PM

View PostLoganDark, on 25 April 2016 - 07:29 PM, said:

View PostAnavrins, on 25 April 2016 - 07:05 PM, said:

View PostLoganDark, on 25 April 2016 - 06:57 PM, said:

-snip-
Well, it's slow, which is a good thing, but not more secure, this construction is as strong as the inner most hash iteration in the loop.
Granted, it's probably never going to be cracked, but stating it's more secure is false, and because of that, having 50 salts is redundant and a of waste space.

Sure, it's not that more secure, but it's more secure nonetheless. Argument or not, it is, but it's not an improvement as much as from plaintext to 1 hash.

The question is: How much speed do you want to trade of for security? And in my opinion the security gained from 1 hash with salt to 50 hashes with 50 salts is not enough for waiting longer to get in and not being able to go in instant after entering the password.

#56 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 25 April 2016 - 07:33 PM

View PostAnavrins, on 25 April 2016 - 07:05 PM, said:

Well, it's slow, which is a good thing, but not more secure, this construction is as strong as the inner most hash iteration in the loop.
Granted, it's probably never going to be cracked, but stating it's more secure is false, and because of that, having 50 salts is redundant and a of waste space.

Wait.. Since when has slow ever been a good thing? Just because one hash or encryption algorithm is slower than another, doesn't mean it's more secure. And in some scenarios, such as a computer lock (where I don't want to wait 10 seconds for my computer to unlock every time I reboot it), I think I'd prefer a faster, less secure algorithm than a slower, slightly more secure one.

#57 LoganDark

  • Members
  • 231 posts
  • LocationMacintosh HD/Users/LoganDark

Posted 25 April 2016 - 07:35 PM

View PostJiloacom, on 25 April 2016 - 07:33 PM, said:

View PostAnavrins, on 25 April 2016 - 07:05 PM, said:

Well, it's slow, which is a good thing, but not more secure, this construction is as strong as the inner most hash iteration in the loop.
Granted, it's probably never going to be cracked, but stating it's more secure is false, and because of that, having 50 salts is redundant and a of waste space.

Wait.. Since when has slow ever been a good thing? Just because one hash or encryption algorithm is slower than another, doesn't mean it's more secure. And in some scenarios, such as a computer lock (where I don't want to wait 10 seconds for my computer to unlock every time I reboot it), I think I'd prefer a faster, less secure algorithm than a slower, slightly more secure one.

Slower deters brute-force. But it's not that much more secure.

#58 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 25 April 2016 - 07:36 PM

View PostLoganDark, on 25 April 2016 - 07:35 PM, said:

Slower deters brute-force. But it's not that much more secure.

If you really want to deter brute-forcing, there are several other options available to you (such as a password attempt limit) instead of making the program slower.

Edited by Jiloacom, 25 April 2016 - 07:36 PM.


#59 LoganDark

  • Members
  • 231 posts
  • LocationMacintosh HD/Users/LoganDark

Posted 25 April 2016 - 07:46 PM

I am working on version 4 of my password lock system. Have suggestions? Now is the time to pitch in.

#60 Luca_S

  • Members
  • 407 posts
  • LocationGermany

Posted 25 April 2016 - 08:16 PM

View PostLoganDark, on 25 April 2016 - 07:46 PM, said:

I am working on version 4 of my password lock system. Have suggestions? Now is the time to pitch in.

View PostLDDestroier, on 25 April 2016 - 07:32 PM, said:

If you'd sacrifice speed and convenience for an insignificant security boost, at least have a config option to make it hash once.

Edit: I tested it:

Hash 1 time: 0.05 seconds
Hash 50 times: 2.5 seconds

We are talking about 2.45 seconds longer for a really insignificant change of security.

Edited by Luca_S, 25 April 2016 - 08:19 PM.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users