239 posts
Location
Macintosh HD/Users/LoganDark
Posted 07 March 2016 - 11:21 PM
LoganDark's Password Lock SystemHello! I have only a few hundred words to please you before you click away, so before you go, let me introduce you to my password lock system. The newest versions (V3 onward) use salting to encrypt the passwords.
What's salting, you ask? Well let me give you the simple version. Salting is a random string added to the end of a password before it gets hashed (encrypted). You need the password
and the salt to crack the password, so it is that much more secure. The salt is integrated into the hash itself (not concatenated), so a rainbow table won't work as well as you'd hope…
What makes my system better, you ask? No other system that I know of is this secure. Of course the features are not something to rave about, but the security is unbelievable.
Big changes are written next to the versions in bold. Those changes persist onto newer versions unless otherwise noted. Versions in italics aren't released yet or are no longer available.
Versions:
- V1 (pastebin run Gs1GRuWD)
- V2 (pastebin get PdYf5rwy startup) Encrypts multiple times
- V3 (pastebin get ghasE8KL startup) Uses salting
- V4 (pastebin get BhPk3z1E startup) ComputerCraft's first pbkdf2 lock :)/> (credit to Anavrins :D/>)
- this password lock is pretty much abandoned by now so i'll just say it right here: don't expect an update
Add-ons:
- Updater (pastebin get X4nFw8Bg update) (updates to latest version OR installs the latest version)
Please reply leaving feedback! It helps me make future versions!
License
Edited on 02 August 2016 - 06:40 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 16 March 2016 - 06:03 PM
Comments below were posted after version 2 of my password lock had been released.
To view comments for the most recent version of my system, click here.Edited on 17 May 2016 - 07:19 PM
1715 posts
Location
ACDC Town
Posted 16 March 2016 - 07:56 PM
Ohh, it uses SHA256! Good LoganDark! I should go change my encrypted lock to use that instead.
Although, IMO it uses too many sleep() calls, and it DOES look a bit too basic for my taste. But it gets the job done, and is indeed much harder to brute-force than your previous one.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 17 March 2016 - 12:58 AM
Ohh, it uses SHA256! Good LoganDark! I should go change my encrypted lock to use that instead.
Although, IMO it uses too many sleep() calls, and it DOES look a bit too basic for my taste. But it gets the job done, and is indeed much harder to brute-force than your previous one.
Although, brute-forcing would not be hard outside of ComputerCraft, on a real machine, possibly running brute-force as it's OS (lol), with real-world hashing with real good speed.
What are you talking about, too many sleep() calls?
1715 posts
Location
ACDC Town
Posted 17 March 2016 - 01:56 AM
What are you talking about, too many sleep() calls?
Lines 233, 248, 252. It's kinda annoying waiting two seconds to get to the shell.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 17 March 2016 - 07:32 AM
What are you talking about, too many sleep() calls?
Lines 233, 248, 252. It's kinda annoying waiting two seconds to get to the shell.
If there were no sleep calls there, the user wouldn't be able to read the text.
Edit: The user might want to know what's going on if they're suddenly asked for the password again.
Edited on 17 March 2016 - 06:32 AM
2679 posts
Location
You will never find me, muhahahahahaha
Posted 17 March 2016 - 11:22 AM
Better tell the user to press a key.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 17 March 2016 - 06:57 PM
Better tell the user to press a key.
Like "press any key to continue"?
339 posts
Location
Computer, Base, SwitchCraft, Cube-earth, Blockiverse, Computer
Posted 17 March 2016 - 07:00 PM
Ohh, it uses SHA256! Good LoganDark! I should go change my encrypted lock to use that instead.
Although, IMO it uses too many sleep() calls, and it DOES look a bit too basic for my taste. But it gets the job done, and is indeed much harder to brute-force than your previous one.
Although, brute-forcing would not be hard outside of ComputerCraft, on a real machine, possibly running brute-force as it's OS (lol), with real-world hashing with real good speed.
What are you talking about, too many sleep() calls?
Yanno, I have a system that can crack a non-salted SHA in about 5 seconds.
323 posts
Location
Boston, MA
Posted 17 March 2016 - 07:00 PM
Better tell the user to press a key.
Like "press any key to continue"?
Yeah, it's quite easy.
<code here>
print("Press any key to continue")
sleep(0.2)--make sure any key press from the state before is up
os.pullEventRaw( "key_up" )
<mode code here>
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 17 March 2016 - 10:12 PM
Better tell the user to press a key.
Like "press any key to continue"?
Yeah, it's quite easy.
<code here>
print("Press any key to continue")
sleep(0.2)--make sure any key press from the state before is up
os.pullEventRaw( "key_up" )
<mode code here>
Uhh, I'm not dumb.
Thanks for your help, but I don't need help unless I ask for it.
Ohh, it uses SHA256! Good LoganDark! I should go change my encrypted lock to use that instead.
Although, IMO it uses too many sleep() calls, and it DOES look a bit too basic for my taste. But it gets the job done, and is indeed much harder to brute-force than your previous one.
Although, brute-forcing would not be hard outside of ComputerCraft, on a real machine, possibly running brute-force as it's OS (lol), with real-world hashing with real good speed.
What are you talking about, too many sleep() calls?
Yanno, I have a system that can crack a non-salted SHA in about 5 seconds.
What makes you think I really care?
756 posts
Posted 18 March 2016 - 01:53 AM
Yanno, I have a system that can crack a non-salted SHA in about 5 seconds.
Again with these claims.
Your system is called Google, and it doesn't work with all passwords… otherwise…
Spoiler
I COULD unhash an address… If I knew the SHA256 and the key… Yeah, thanks, krist.ceriat.net for not providing the SHA's and the keys.
Let's say the account with password "a", has an address "kxxk8invlf" and a privatekey "9c61cce6bae9ac864b60238532ac8ce1a73006d943b44e060259e50363f4aebd-000" which is 68 characters long.
The hash stored in the database is sha256("address..privatekey"), you know the address, but you still need to figure out the privatekey.
Is it me or you are claiming to be able to crack a 68 characters long password?
Edited on 18 March 2016 - 12:56 AM
41 posts
Posted 21 March 2016 - 03:56 PM
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.
1610 posts
Posted 21 March 2016 - 04:56 PM
Ohh, it uses SHA256! Good LoganDark! I should go change my encrypted lock to use that instead.
Although, IMO it uses too many sleep() calls, and it DOES look a bit too basic for my taste. But it gets the job done, and is indeed much harder to brute-force than your previous one.
Although, brute-forcing would not be hard outside of ComputerCraft, on a real machine, possibly running brute-force as it's OS (lol), with real-world hashing with real good speed.
What are you talking about, too many sleep() calls?
Yanno, I have a system that can crack a non-salted SHA in about 5 seconds.
Crack this. Unsalted SHA256 hash. 9 characters, lowercase a-z and numbers only.
3cc5ac3f7e28a9f177e63827899fd3d7d3d96d006ee5f5c86fbbb4ccfc9e1aa3
Edited on 21 March 2016 - 03:58 PM
2679 posts
Location
You will never find me, muhahahahahaha
Posted 21 March 2016 - 05:37 PM
Ohh, it uses SHA256! Good LoganDark! I should go change my encrypted lock to use that instead.
Although, IMO it uses too many sleep() calls, and it DOES look a bit too basic for my taste. But it gets the job done, and is indeed much harder to brute-force than your previous one.
Although, brute-forcing would not be hard outside of ComputerCraft, on a real machine, possibly running brute-force as it's OS (lol), with real-world hashing with real good speed.
What are you talking about, too many sleep() calls?
Yanno, I have a system that can crack a non-salted SHA in about 5 seconds.
Crack this. Unsalted SHA256 hash. 9 characters, lowercase a-z and numbers only.
3cc5ac3f7e28a9f177e63827899fd3d7d3d96d006ee5f5c86fbbb4ccfc9e1aa3
Nowhere to be found on the internetz.
339 posts
Location
Computer, Base, SwitchCraft, Cube-earth, Blockiverse, Computer
Posted 21 March 2016 - 05:37 PM
Well, let's fire up Hashcat and see what this baby can really do.
EDIT: Not big enough dictionary. (Yes I'm using a dict attack.)
Edited on 21 March 2016 - 04:41 PM
339 posts
Location
Computer, Base, SwitchCraft, Cube-earth, Blockiverse, Computer
Posted 21 March 2016 - 05:44 PM
Note that this is the same PC I mine Krist on.
2679 posts
Location
You will never find me, muhahahahahaha
Posted 21 March 2016 - 05:50 PM
There is no way the dictionary is big enough. There are 2^256 ( 1.15 * 10^77 ) possible sha256 hashes, and there are only around 10^81 atoms in the universe, so no way the dictionary is big enough.
756 posts
Posted 21 March 2016 - 06:49 PM
Well, let's fire up Hashcat and see what this baby can really do.
EDIT: Not big enough dictionary. (Yes I'm using a dict attack.)
Maybe go with bruteforce and you can get back to us in a year.
That's around 6.307 millions times more than what you claimed.
Edited on 21 March 2016 - 07:20 PM
1610 posts
Posted 21 March 2016 - 08:04 PM
Well, let's fire up Hashcat and see what this baby can really do.
EDIT: Not big enough dictionary. (Yes I'm using a dict attack.)
Note that this is the same PC I mine Krist on.
So much for cracking it in under five seconds.
339 posts
Location
Computer, Base, SwitchCraft, Cube-earth, Blockiverse, Computer
Posted 22 March 2016 - 05:23 PM
I under-estimated SHA. MD5 is a lot easier. Please use COMMON words, and not words like "ghsiejsogjrisie234tkdksowajsk" which isn't even a word.
2679 posts
Location
You will never find me, muhahahahahaha
Posted 22 March 2016 - 05:25 PM
I under-estimated SHA. MD5 is a lot easier. Please use COMMON words, and not words like "ghsiejsogjrisie234tkdksowajsk" which isn't even a word.
Why not? My password can very well be "ghsiejsogjrisie234tkdksowajsk".
756 posts
Posted 22 March 2016 - 06:49 PM
I under-estimated SHA. MD5 is a lot easier. Please use COMMON words, and not words like "ghsiejsogjrisie234tkdksowajsk" which isn't even a word.
Please stop…
Edited on 22 March 2016 - 06:11 PM
477 posts
Location
Germany
Posted 22 March 2016 - 07:25 PM
I under-estimated SHA. MD5 is a lot easier. Please use COMMON words, and not words like "ghsiejsogjrisie234tkdksowajsk" which isn't even a word.
Please choose one of these 3 Passwords:
1. lolcatzwillruletheworld
2. mypasswordissolongitisuncrackable
3. ihavenoideawhattowritehere
And tell me the sha256 hash of it. I bet I can crack it in 5 seconds.
1610 posts
Posted 22 March 2016 - 08:21 PM
I under-estimated SHA. MD5 is a lot easier. Please use COMMON words, and not words like "ghsiejsogjrisie234tkdksowajsk" which isn't even a word.
Well, you said SHA. There's a reason MD5 hasn't been used for passwords for several years at this point…
477 posts
Location
Germany
Posted 23 March 2016 - 08:39 AM
What are you talking about, too many sleep() calls?
Lines 233, 248, 252. It's kinda annoying waiting two seconds to get to the shell.
If there were no sleep calls there, the user wouldn't be able to read the text.
Edit: The user might want to know what's going on if they're suddenly asked for the password again.
You don't actually need the sleep at 248.
Edited on 23 March 2016 - 07:44 AM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 24 March 2016 - 06:32 AM
What are you talking about, too many sleep() calls?
Lines 233, 248, 252. It's kinda annoying waiting two seconds to get to the shell.
If there were no sleep calls there, the user wouldn't be able to read the text.
Edit: The user might want to know what's going on if they're suddenly asked for the password again.
You don't actually need the sleep at 248.
Good point. I'll consider it when making the next version.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 29 March 2016 - 03:58 PM
Comments below were posted after version 3 of my password lock had been released.
To view comments for the most recent version of my system, click here.Edited on 17 May 2016 - 07:18 PM
8543 posts
Posted 29 March 2016 - 05:39 PM
Threads merged. Please stick to one topic per program. Feel free to edit the first post and topic title.
1715 posts
Location
ACDC Town
Posted 29 March 2016 - 06:59 PM
I think the lock is pretty good. It's certainly more animated than the previous version, even when hashing (which, wouldn't that make it take longer to hash, slightly?)
But mine looks better!!!
756 posts
Posted 29 March 2016 - 07:16 PM
That's an interesting approach to salting I gotta say :P/>
Looks nice and simple, the only comments I have is about the SHA2 code, you can make the whole process faster by
using my implementation of it, however if you want to stick with GravScore's one, I'd suggest fixing the bug I mentioned in his thread
Spoiler
Also, replacing line 136 with local extra = -(len + 9)%64 will fix the padding error in OP's implementation.
line 135 in your code ;)/>Edited on 29 March 2016 - 05:17 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 29 March 2016 - 07:27 PM
I think the lock is pretty good. It's certainly more animated than the previous version, even when hashing (which, wouldn't that make it take longer to hash, slightly?)
But mine looks better!!!
Nice space link.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 29 March 2016 - 07:34 PM
That's an interesting approach to salting I gotta say :P/>/>/>
Looks nice and simple, the only comments I have is about the SHA2 code, you can make the whole process faster by
using my implementation of it, however if you want to stick with GravScore's one, I'd suggest fixing the bug I mentioned in his thread
Spoiler
Also, replacing line 136 with local extra = -(len + 9)%64 will fix the padding error in OP's implementation.
line 135 in your code ;)/>/>/>
Fixed
Edit: Wanna know a cool fact? The salting seed (that seemingly random jumble of letters and numbers) is the full alphabet in uppercase and lowercase, scrambled beyond recognition with 1234567890 salt (get it? nvm) on top.
Edited on 29 March 2016 - 05:45 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 01 April 2016 - 03:30 PM
[edit: sorry, quoted wrong post]
I think the lock is pretty good. It's certainly more animated than the previous version, even when hashing (which, wouldn't that make it take longer to hash, slightly?)
But mine looks better!!!
Funny, I was playing Portal 2.
"HOW'S YOUR DAY, BECAUSE I'M A POTATO!" - GLaDOS pecked by birds.
Edited on 01 April 2016 - 11:02 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 05 April 2016 - 06:30 PM
I think the lock is pretty good. It's certainly more animated than the previous version, even when hashing (which, wouldn't that make it take longer to hash, slightly?)
But mine looks better!!!
Which one would you choose: Looks or security? It's hard to have both.
756 posts
Posted 05 April 2016 - 07:07 PM
Which one would you choose: Looks or security? It's hard to have both.
I don't see why looks would impair security, it's usually the convenience that's a problem when designing security applications.
Example, most CC locks are good, but you can't make a password reminder thing without giving away some security, Krist's addresses are robust, but you'll loose everything if you forget your pwd, no password recovery either.
Edited on 05 April 2016 - 05:08 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 05 April 2016 - 08:43 PM
Which one would you choose: Looks or security? It's hard to have both.
I don't see why looks would impair security, it's usually the convenience that's a problem when designing security applications.
Example, most CC locks are good, but you can't make a password reminder thing without giving away some security, Krist's addresses are robust, but you'll loose everything if you forget your pwd, no password recovery either.
Which one would you choose: Looks or security? It's h-a-r-d (not impossible) to have both.
756 posts
Posted 05 April 2016 - 10:08 PM
Which one would you choose: Looks or security? It's h-a-r-d (not impossible) to have both.
You don't get what I'm saying, you could make your lock very visually appealing and it would not improve nor degrade its security back-end.
What I meant is that there's a trade-off for user conveniences in exchange of security, such as password recovery, security questions.
The visuals of a program has nothing to do with the security of it.
tl;dr, It's
e-a-s-y to have both looks and security, not so much if you want a password recovery mechanism.
Edited on 05 April 2016 - 08:19 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 05 April 2016 - 10:59 PM
Which one would you choose: Looks or security? It's h-a-r-d (not impossible) to have both.
You don't get what I'm saying, you could make your lock very visually appealing and it would not improve nor degrade its security back-end.
What I meant is that there's a trade-off for user conveniences in exchange of security, such as password recovery, security questions.
The visuals of a program has nothing to do with the security of it.
tl;dr, It's
e-a-s-y to have both looks and security, not so much if you want a password recovery mechanism.
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.
756 posts
Posted 06 April 2016 - 12:51 AM
Again, completely missing the point… I'm done, I wish you good luck with your programs.
Edited on 05 April 2016 - 10:54 PM
1715 posts
Location
ACDC Town
Posted 06 April 2016 - 02:27 AM
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.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 10 April 2016 - 03:37 AM
…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/>
1715 posts
Location
ACDC Town
Posted 10 April 2016 - 05:22 AM
Nooooo! Typing mistakes! My only weakness!
…I meant it's a computer lock that also works as a door lock.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 10 April 2016 - 05:46 AM
Nooooo! [snip]
Isn't that supposed to have 4 o's only? :P/>
1715 posts
Location
ACDC Town
Posted 10 April 2016 - 05:21 PM
Nooooo! [snip]
Isn't that supposed to have 4 o's only? :P/>
NOOOOOOOOOO!!!
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 10 April 2016 - 10:44 PM
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/>
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 25 April 2016 - 06:13 PM
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 on 25 April 2016 - 04:14 PM
477 posts
Location
Germany
Posted 25 April 2016 - 06: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
756 posts
Posted 25 April 2016 - 07: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 on 25 April 2016 - 05:59 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 25 April 2016 - 08:00 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.
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/>
477 posts
Location
Germany
Posted 25 April 2016 - 08:04 PM
-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.
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
756 posts
Posted 25 April 2016 - 08:05 PM
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 on 25 April 2016 - 06:07 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 25 April 2016 - 08:29 PM
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.
1715 posts
Location
ACDC Town
Posted 25 April 2016 - 08: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.
477 posts
Location
Germany
Posted 25 April 2016 - 08:32 PM
-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.
598 posts
Location
The United States
Posted 25 April 2016 - 08:33 PM
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.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 25 April 2016 - 08:35 PM
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.
598 posts
Location
The United States
Posted 25 April 2016 - 08:36 PM
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 on 25 April 2016 - 06:36 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 25 April 2016 - 08:46 PM
I am working on version 4 of my password lock system. Have suggestions? Now is the time to pitch in.
477 posts
Location
Germany
Posted 25 April 2016 - 09:16 PM
I am working on version 4 of my password lock system. Have suggestions? Now is the time to pitch in.
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 on 25 April 2016 - 07:19 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 25 April 2016 - 11:29 PM
I am working on version 4 of my password lock system. Have suggestions? Now is the time to pitch in.
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.
I've already considered that. The answer: completely ditching 50 hashes for 1.
756 posts
Posted 26 April 2016 - 12:11 AM
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.
It slows down bruteforce, however the way he implements his iterations process renders it useless, an attacker would only have to find a collision with one hash iteration to get the same collision with 50, which is why I said that 50 salts is redundant.
Things like bcrypt and pbkdf2 doesn't do this nested approach and can be easily fine tuned for CC to be not too slow and still reduce the efficacy of bruteforce.
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.
Unless you want to manually bruteforce by hand, that'd be a good way to defend it, but here we're talking as if the hash and salt get known to the attacker, bypassing attempts limits.
I would also recommend using my implementation of SHA2, it's way faster than GravScore's, which means running 50 iterations would be faster that it is currently.
I will also be looking to implement pbkdf2 in CC today or tomorrow, if you're interested in using that for your lock.
Edited on 25 April 2016 - 10:15 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 26 April 2016 - 12:13 AM
-snip-
I would also recommend using my implementation of SHA2, -snip-
Can you create a version which has the bit32 functions included? Mimic doesn't have bit32, and bit doesn't have blshift (or brshift; can't remember).
756 posts
Posted 26 April 2016 - 12:21 AM
Can you create a version which has the bit32 functions included? Mimic doesn't have bit32, and bit doesn't have blshift (or brshift; can't remember).
The SHA2 link in my profile already selects the correct functions whether bit32 is present or not. Also mimic is not a good emulator…
Edited on 26 April 2016 - 12:51 AM
756 posts
Posted 30 April 2016 - 07:04 AM
If you want to try out
pbkdf2, I added it to my sha256 file
http://pastebin.com/6UV4qfNF.
Functionality is
pbkdf2(password, salt, iter, dklen)Password and salt are self explanatory, iter is the number of iteration, more iteration makes it more slow, you can fine tune it to be not too slow but not so fast.
You don't need to touch dklen, this is the desired output length in bytes, it's defaulted to 32 and shouldn't be more than that for password storage, it's pretty much only useful for when you need more than 32 bytes of key material for ciphers and other.
This is a proper algorithm to make bruteforce slower, it's used in things like iPhone's pins, LastPass master keys and more.
It also passes the test vectors at
https://stackoverflo...a2-test-vectorsEdited on 30 April 2016 - 05:27 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 01 May 2016 - 02:45 AM
If you want to try out
pbkdf2, I added it to my sha256 file
http://pastebin.com/6UV4qfNF.
Functionality is
pbkdf2(password, salt, iter, dklen)Password and salt are self explanatory, iter is the number of iteration, more iteration makes it more slow, you can fine tune it to be not too slow but not so fast.
You don't need to touch dklen, this is the desired output length in bytes, it's defaulted to 32 and shouldn't be more than that for password storage, it's pretty much only useful for when you need more than 32 bytes of key material for ciphers and other.
This is a proper algorithm to make bruteforce slower, it's used in things like iPhone's pins, LastPass master keys and more.
It also passes the test vectors at
https://stackoverflo...a2-test-vectors
Can you give a version with just pbkdf2 and make it as compact as possible?
756 posts
Posted 01 May 2016 - 02:59 AM
It's pretty much that, it needs SHA2 and HMAC to work, it's as compact as it can be.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 01 May 2016 - 03:00 AM
It's pretty much that, it needs SHA2 and HMAC to work, it's as compact as it can be.
Okay, thanks.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 01 May 2016 - 03:28 AM
Fatal JavaScript error using Mimic.
pbkdf2(data, salt, 1, 64) --# Using 64 because I want to.
Edited on 01 May 2016 - 01:30 AM
756 posts
Posted 01 May 2016 - 03:45 AM
Fatal JavaScript error using Mimic.
pbkdf2(data, salt, 1, 64) --# Using 64 because I want to.
Don't use mimic, as you can see, it causes Javascript errors, that's unrelated to my code.
How are you using my code?, are you loading it via os.loadAPI, or are you pasting it directly into you code?
If you're pasting it in, can I see your whole code that causes the error?
The reason why I recommend the default 32 is because using larger than that is gonna trigger the code to go through the same amount of iterations twice, and since SHA2 originally outputs 32 bytes, somebody attempting to crack it would only need to compute the first 32 bytes, skipping the calculation time of the second 32 bytes chunk.
Basically, 64 is going to run twice as slow, without benefits, precious time that could be spent into more iterations instead.
Edited on 01 May 2016 - 02:22 AM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 17 May 2016 - 08:34 PM
Comments below were posted after version 4 of my password lock had been released.
To view comments for the most recent version of my system, click here.Edited on 17 May 2016 - 07:19 PM
1715 posts
Location
ACDC Town
Posted 17 May 2016 - 08:42 PM
Man, version three of your lock was totally tubular!
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 17 May 2016 - 08:43 PM
Good tubular or bad tubular? I'm confused
Edited on 17 May 2016 - 07:15 PM
756 posts
Posted 17 May 2016 - 09:54 PM
Now that's pretty sweet, first public lock using pbkdf2 :P/>
Few minor things that caught my attention, both in the genSalt function, the seed string contains repeated characters (1, P, p)
There's also an unnecessary math.randomseed(random(0,65534)) which will end up only producing a set of 65535 unique salt, instead of 6332.
Edited on 17 May 2016 - 07:55 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 17 May 2016 - 09:56 PM
Now that's pretty sweet, first public lock using pbkdf2 :P/>
Few minor things that caught my attention, both in the genSalt function, the seed string contains repeated characters (1, P, p)
There's also an unnecessary math.randomseed(random(0,65534)) which will end up only producing a set of 65535 unique salt, instead of 6332.
Thanks, will consider in next version
edit: 65535 is nothing compared to
Spoiler
3792255400000000000000000000000000000000000000000000000000will consider in next version xD
Edited on 17 May 2016 - 08:05 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 17 May 2016 - 10:03 PM
Also, I don't think salt is an issue when we have pbkdf2 here.
756 posts
Posted 17 May 2016 - 11:06 PM
The salt's purpose is to defend against rainbow-tables, that is, pregenerated table of "pass+salt = hash", sure they might take a long time to make, but once it's made, you don't need to recalculate it.
That means I can compute 65535 tables that contains, example, the list of 100k most commonly used passwords, that seems like a lot, but it's very much more doable than creating 6332 table of 100k entries :P/>
Once I've made these table, and somehow got hold of multiple secure.password files from the lock, I can instantaneously find all the passwords, without recomputing all of the 100k password, assuming they are in the list.
This apply whether you're using plain sha256, hmac, even pbkdf2.
Remember that pbkdf2's purpose is to slowdown computation by making the hashing process inherently slow.
Suuuuure, most likely nobody is going to go on ahead and create such lists for your lock specifically, all of this is a bit overboard in the context of CC, but I like to take this kind of things seriously even in CC, it helps to develop good practices which might apply if you ever develop any serious application that deals with passwords, since these kinds of attacks are a real, practical threat for larger applications.
Edited on 17 May 2016 - 09:08 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 17 May 2016 - 11:10 PM
password.secure*
35 posts
Location
United States of America
Posted 02 June 2016 - 10:28 PM
Good idea, you could use a rainbow table though to break the encryption.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 02 June 2016 - 10:30 PM
Good idea, you could use a rainbow table though to break the encryption.
yes, but I will likely release a new version before that can be calculated
besides, the salts can be calculated (at the moment) but the password can not
477 posts
Location
Germany
Posted 03 June 2016 - 04:52 PM
Good idea, you could use a rainbow table though to break the encryption.
yes, but I will likely release a new version before that can be calculated
besides, the salts can be calculated (at the moment) but the password can not
I don't think you got the problem. You can pre-calculate some top passwords list with all your possible salts. But if you use 63 possibilities that's pretty much impossible.
Just remove line 212.
Edited on 03 June 2016 - 02:53 PM
756 posts
Posted 03 June 2016 - 04:53 PM
yes, but I will likely release a new version before that can be calculated
Just saying that fixing the genSalt function will not break computers already protected with V4.
It's only used when creating the password, computers with their password already set up won't be affected.
35 posts
Location
United States of America
Posted 03 June 2016 - 05:07 PM
People overthink stuff too much.
I can crack it in five seconds 4 steps.
Get floppy disk
Make a new program named started with the code
print("Look, its gone!")
Put it in there computer
Done
You cant beat the ol floppy disk
Edited on 03 June 2016 - 03:07 PM
756 posts
Posted 03 June 2016 - 05:35 PM
In recent CC versions, there's a way to disable floppy disk startups.
Like I said in a previous post, I like to overthink stuff as if it was a serious application, it helps develop good habits, which is trivial in the context of CC, but much less in others.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 03 June 2016 - 10:22 PM
I'd like your opinion on something real quick.
Do you think my password system would benefit from changing the salt every time a user enters his password correctly?
For security reasons?
1715 posts
Location
ACDC Town
Posted 03 June 2016 - 10:33 PM
How would that work? I think a cool thing to have is the salt of the password to be a scrabbled version of the password.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 03 June 2016 - 10:34 PM
How would that work? I think a cool thing to have is the salt of the password to be a scrabbled version of the password.
No. Having a salt derived from the password would defeat the purpose of the salt, which is to add an extra layer of security.
1715 posts
Location
ACDC Town
Posted 03 June 2016 - 10:39 PM
How would that work? I think a cool thing to have is the salt of the password to be a scrabbled version of the password.
No. Having a salt derived from the password would defeat the purpose of the salt, which is to add an extra layer of security.
Why is that? The cracker doesn't know the key, and to use a rainbow table, you need the salt. Maybe I'm missing something?
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 03 June 2016 - 10:40 PM
How would that work? I think a cool thing to have is the salt of the password to be a scrabbled version of the password.
No. Having a salt derived from the password would defeat the purpose of the salt, which is to add an extra layer of security.
Why is that? The cracker doesn't know the key, and to use a rainbow table, you need the salt. Maybe I'm missing something?
yes, but if it's derived from the password, the password is already the salt, it just takes a few steps that will always be the same to make the salt.
the purpose of a salt is having another part of the password to calculate
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 03 June 2016 - 10:54 PM
How would that work? I think a cool thing to have is the salt of the password to be a scrabbled version of the password.
No. Having a salt derived from the password would defeat the purpose of the salt, which is to add an extra layer of security.
Why is that? The cracker doesn't know the key, and to use a rainbow table, you need the salt. Maybe I'm missing something?
in other words, the cracker won't need to know the salt, just the rainbow table, because you can calculate the salt from the passwords, ruining the entire purpose of the salt
1715 posts
Location
ACDC Town
Posted 04 June 2016 - 01:14 AM
How would that work? I think a cool thing to have is the salt of the password to be a scrabbled version of the password.
No. Having a salt derived from the password would defeat the purpose of the salt, which is to add an extra layer of security.
Why is that? The cracker doesn't know the key, and to use a rainbow table, you need the salt. Maybe I'm missing something?
in other words, the cracker won't need to know the salt, just the rainbow table, because you can calculate the salt from the passwords, ruining the entire purpose of the salt
That's a fair point…
1080 posts
Location
In the Matrix
Posted 06 June 2016 - 10:22 PM
Do you also know that you shouldn't try to resalt a password because then that requires you to store a password on disk to resalt it, unless for whatever reason you decide to resalt the hash, which would require you to keep track of two salts in order per user.
Edited on 07 June 2016 - 12:31 PM
8543 posts
Posted 07 June 2016 - 02:32 PM
Moved to Programs.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 07 June 2016 - 02:47 PM
Do you also know that you shouldn't try to resalt a password because then that requires you to store a password on disk to resalt it, unless for whatever reason you decide to resalt the hash, which would require you to keep track of two salts in order per user.
No, resalting uses the input from the user (which we know is the correct one because it hashes the same as the stored password when using the old salt) with a new salt to create a new hash which overwrites the previous one. I've tested it and it's currently working.
Edit: I don't know if I should keep the salting functionality at all, because it's stored in the file anyway…
Edited on 07 June 2016 - 12:50 PM
1080 posts
Location
In the Matrix
Posted 07 June 2016 - 05:43 PM
That is a way I hadn't thought about, probably still not the best to change. I believe that most companies store their salts in a separate location, of course I've never seen how it's done so I could be completely wrong.
756 posts
Posted 07 June 2016 - 06:45 PM
I've made a big ol' paragraph explaining why salts are important, so you should probably keep that there.
Salts are always stored with the hashes, they're meant to be "visible", they're not secrets like your passwords.
The only important thing about salts you should be worried is that they should not be predictable, that is, not within a list of 65535 possibilities.
Other than that, the way Logan is currently doing is perfectly fine.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 07 June 2016 - 07:35 PM
I've made a big ol' paragraph explaining why salts are important, so you should probably keep that there.
Salts are always stored with the hashes, they're meant to be "visible", they're not secrets like your passwords.
The only important thing about salts you should be worried is that they should not be predictable, that is, not within a list of 65535 possibilities.
Other than that, the way Logan is currently doing is perfectly fine.
what big ol' paragraph?
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 07 June 2016 - 07:40 PM
Moved to Programs.
this is definitely a utility, but okay…
477 posts
Location
Germany
Posted 07 June 2016 - 07:57 PM
Moved to Programs.
this is definitely a utility, but okay…
We discussed that earlier and obviously Lyqyd(or some other mod) didn't like that discussion to be here(Else he wouldn't have cut it off).
But now to the salt:
If the user get's access to the files of the computer(Disk, or maybe an evil server owner) and your password is not salted he can use a rainbow table, that he calculates once and then uses EVERY time he finds a badly programmed password lock. If you salt your password the attacker needs to recalculate the rainbow table for every salts, therefore making cracking slow. So keep the functionality.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 07 June 2016 - 07:59 PM
Moved to Programs.
this is definitely a utility, but okay…
We discussed that earlier and obviously Lyqyd(or some other mod) didn't like that discussion to be here(Else he wouldn't have cut it off).
But now to the salt:
If the user get's access to the files of the computer(Disk, or maybe an evil server owner) and your password is not salted he can use a rainbow table, that he calculates once and then uses EVERY time he finds a badly programmed password lock. If you salt your password the attacker needs to recalculate the rainbow table for every salts, therefore making cracking slow. So keep the functionality.
But you don't need a rainbow table for the salt, you can just use the one stored in the file. That's what I'm talking about, just use the same rainbow table with whatever salt is in the file.
756 posts
Posted 07 June 2016 - 08:00 PM
what big ol' paragraph?
A little bit of searching doesn't hurt…
http://www.computerc...post__p__251479But you don't need a rainbow table for the salt, you can just use the one stored in the file. That's what I'm talking about, just use the same rainbow table with whatever salt is in the file.
That's why I made that paragraph, because you don't seem to know how it works and why it's important.
Edited on 07 June 2016 - 06:04 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 07 June 2016 - 08:03 PM
what big ol' paragraph?
A little bit of searching doesn't hurt…
http://www.computerc...post__p__251479
oh, wait, you were talking about the table of completed hashes?
yes, that would be hard to do
then I'm keeping the salt
1080 posts
Location
In the Matrix
Posted 07 June 2016 - 08:37 PM
What? Now I'm curious, are you salting the hashed password? Or the password and then hashing it?
Edit: Nvm, you didn't realize it was a pregenerated table of hashes.
I will say tho, the reason why the salt is great, is because while being random and hard to guess and tack on if you just have the hash, it pads out the password, thus making the number of possibilities of your password going up exponentially.
Edited on 07 June 2016 - 06:39 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 07 June 2016 - 08:38 PM
What? Now I'm curious, are you salting the hashed password? Or the password and then hashing it?
Edit: Nvm, you didn't realize it was a pregenerated table of hashes.
I'm salting the password then hashing it. Salting the hash is extremely insecure and horrible…
477 posts
Location
Germany
Posted 07 June 2016 - 08:43 PM
EDIT: didn't see the new page, derp, don't need to read this.
Spoiler
Moved to Programs.
this is definitely a utility, but okay…
We discussed that earlier and obviously Lyqyd(or some other mod) didn't like that discussion to be here(Else he wouldn't have cut it off).
But now to the salt:
If the user get's access to the files of the computer(Disk, or maybe an evil server owner) and your password is not salted he can use a rainbow table, that he calculates once and then uses EVERY time he finds a badly programmed password lock. If you salt your password the attacker needs to recalculate the rainbow table for every salts, therefore making cracking slow. So keep the functionality.
But you don't need a rainbow table for the salt, you can just use the one stored in the file. That's what I'm talking about, just use the same rainbow table with whatever salt is in the file.
Ok, I'll give you an example, here is my really basic precalculated rainbow table of the first 3 passwords I get into my head:
123456 -> 8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92
password -> 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
logmein -> e14b7271eccebd070f79759e979e35bb2f1bce919eb421ac4cdc26417a318d13
Remember this would usually be a lot more than 3 passwords and would take hours/days to generate. Now if there is a bad password lock that doesn't use salting, this might happen(we are looking at the password file):
{
password="8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92"
}
Wait a minute… that's actually the hash of the password 123456, so we got the password. https://crackstation.net/ has a pretty big database.
But now what happens if we salt:
Our config file changes to
{
salt="hjUIlaj"
password="844448acf56034ff5ca16b648a75f558fb23d23addaaf45772405ae17ec138f3"
}
And we don't know what password "844448acf56034ff5ca16b648a75f558fb23d23addaaf45772405ae17ec138f3" is and neither can tell you crackstation in this case. You would need to re generate your whole rainbow table(Which would take several hours/days) to crack this(Assuming it's not one of the first in these top 100 password lists)What? Now I'm curious, are you salting the hashed password? Or the password and then hashing it?
Edit: Nvm, you didn't realize it was a pregenerated table of hashes.
I'm salting the password then hashing it. Salting the hash is extremely insecure and horrible…
Errm nope. It is horrible but it is not insecure…
Assuming you mean hash(hash(password)..salt)
Edited on 07 June 2016 - 06:46 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 07 June 2016 - 08:46 PM
if you have password HI with salt 12345678 then the rainbow table might have a password called HI12345678 which ends up being the same hash, it wouldn't take much expertise to subtract 12345678 from HI12345678 to get HI.
just an example.
756 posts
Posted 07 June 2016 - 08:50 PM
What? Now I'm curious, are you salting the hashed password? Or the password and then hashing it?
He's using an algorithm called
pbkdf2 that I implemented.
Usage is simple, you feed it the raw password, and an unpredictable salt, you let the rest to the algorithm.
Resalting the hash is not insecure, it's just a unnecessary step.
if you have password HI with salt 12345678 then the rainbow table might have a password called HI12345678 which ends up being the same hash, it wouldn't take much expertise to subtract 12345678 from HI12345678 to get HI.
If you concatenate the salt with the hash, you're doing it wrong, PBKDF2 doesn't concatenate the salt with the password, it is integrated with the hash via HMAC, the whole point of HMAC is to prevent length extention, which is something similar to what you described.
Edited on 07 June 2016 - 06:52 PM
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 07 June 2016 - 08:54 PM
What? Now I'm curious, are you salting the hashed password? Or the password and then hashing it?
He's using an algorithm called
pbkdf2 that I implemented.
Usage is simple, you feed it the raw password, and an unpredictable salt, you let the rest to the algorithm.
Resalting the hash is not insecure, it's just a unnecessary step.
if you have password HI with salt 12345678 then the rainbow table might have a password called HI12345678 which ends up being the same hash, it wouldn't take much expertise to subtract 12345678 from HI12345678 to get HI.
If you concatenate the salt with the hash, you're doing it wrong, PBKDF2 doesn't concatenate the salt with the password, it is integrated with the hash via HMAC.
Oh.
#REKT ANY OTHER PASSWORD SYSTEM, MINE IS OFFICIALLY THE (first) MOST SECURE SYSTEM ON THE FORUMS.
Edit: sorry double post
if you have password HI with salt 12345678 then the rainbow table might have a password called HI12345678 which ends up being the same hash, it wouldn't take much expertise to subtract 12345678 from HI12345678 to get HI.
just an example.
Errrm that is salting the password and then hashing it…
I didn't understand pdbfkdksshspdhj2 until anavrins told me… My system used to concatenate the salt to the password and then hash with SHA256, now it uses PBDKSDGH2.
Edited on 07 June 2016 - 06:53 PM
756 posts
Posted 07 June 2016 - 08:55 PM
#REKT ANY OTHER PASSWORD SYSTEM, MINE IS OFFICIALLY THE (first) MOST SECURE SYSTEM ON THE FORUMS.
You're welcome.
239 posts
Location
Macintosh HD/Users/LoganDark
Posted 08 June 2016 - 12:41 AM
#REKT ANY OTHER PASSWORD SYSTEM, MINE IS OFFICIALLY THE (first) MOST SECURE SYSTEM ON THE FORUMS.
You're welcome.
Thanks lol, without your expertise in cryptography this wouldn't have been possible
89 posts
Posted 28 June 2016 - 08:00 PM
I've made a big ol' paragraph explaining why salts are important, so you should probably keep that there.
Salts are always stored with the hashes, they're meant to be "visible", they're not secrets like your passwords.
The only important thing about salts you should be worried is that they should not be predictable, that is, not within a list of 65535 possibilities.
Other than that, the way Logan is currently doing is perfectly fine.
Yeppity. Love this program very useful
Nobody really cracks hashes anymore, unless your trying to crack your parents windows laptop within the SAM file..but hey whatever. or use chntpw to just remove it.
756 posts
Posted 28 June 2016 - 08:22 PM
Nobody really cracks hashes anymore, unless your trying to crack your parents windows laptop within the SAM file..but hey whatever. or use chntpw to just remove it.
You'd be impressed how wrong you are, there has been a swarm of password breaches recently, most notably LinkedIn, with many other unbreached sites warning their users about password re-use due to databases being cracked.
I understand that going to such lengths in CC is kind of unnecessary, but like I always say, I prefer spreading good habits to peoples who will potentially work on larger projects that requires password storage.
89 posts
Posted 28 June 2016 - 08:29 PM
-SNIPPITY SNIP SNIP-
But yeah I just figured no one wasted their time anymore. I mean the people I associate with only crack the shit hashes. But yeah keep up the good work man! :)/>
EDIT: And trojans mostly steal the passwords, not hash cracking. But yeah you are right to an extent, and I'll grant you an expert in cryptography.
Edited on 28 June 2016 - 06:33 PM
129 posts
Location
I honestly don't know
Posted 18 July 2016 - 03:35 AM
Man, version three of your lock was totally tubular!
I think he means it was a
tubular lock, in which case…..
Edited on 18 July 2016 - 01:41 AM
1715 posts
Location
ACDC Town
Posted 18 July 2016 - 04:02 AM
Is it still secure to hash a password concatenated with a 128-character random 'salt'?
756 posts
Posted 18 July 2016 - 09:24 AM
Is it still secure to hash a password concatenated with a 128-character random 'salt'?
technically yes, though it is better to not simply concatenate them together, it's generally better to use hmac, with the password as the key and the salt as the message, or ideally pbkdf2, bcrypt, or others algorithms that has a specific argument for salts.