|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On October 28 2017 06:07 Blisse wrote:
If it's just passing around the password as a string parameter then it's fine.
If the password is persisted in any way then no.
"data stays inside the app" means lots of things. Just because data is saved to app storage doesn't mean malicious users can't easily access the data.
Right, it's just a string field in an object that doesn't get saved. Thanks for the answer.
On October 28 2017 06:12 tofucake wrote:
salting the hash costs next to nothing and is far more secure than not.
you not wanting to salt means you either don't care (bad), don't think it matters (bad), don't want to do it because you don't understand salt (bad, but not as bad as the others), or "need" every possible byte of storage you can get for some other reason (bad)
tl;dr just fucking salt the password
It's a proof of concept app(not on the app store) and I didn't want to spend the time implementing it, though I probably will now just for learning's sake.
On October 28 2017 02:40 Blitzkrieg0 wrote:Show nested quote +On October 28 2017 02:05 WarSame wrote:
My database is on the phone, so they can't use a rainbow table against it I think. I was thinking more of concerns surrounding passing the hashed value around.
Also, I'm using SHA-256, so I should be fine on that end. The database being on your phone doesn't protect you against a rainbow table. If you have a million users and you hash all the passwords then you're going to have a bunch of duplicate entries in your database as anyone with the same password will have an identical entry after the hash. You add the salt so that each of those will hash to a different value and if an adversary brute forces one password they don't have everyone else's password who was using that same value. Salts protect the collective. They're useless if the adversary is brute forcing one password. The rainbow table is just a list of what common passwords hash to with various algorithms. By utilizing a salt the adversary has to generate a rainbow table for every salt instead of having a master copy.
Thanks, I'd misunderstood what a rainbow table actually was and your info makes me a lot more wary of it.
EDIT: After more reading, WOW, hashing without salting is awful.
|
After you have learned, you should then abandon ever doing your own auth scheme by yourself and use oath from something else. Too easy to fuck up. Not quite as hard and fast a rule as "don't roll your own crypto", but still for anything real don't do it on your own. (Fine for this test app)
|
Hyrule19150 Posts
On October 28 2017 07:04 WarSame wrote:Show nested quote +On October 28 2017 06:07 Blisse wrote:
If it's just passing around the password as a string parameter then it's fine.
If the password is persisted in any way then no.
"data stays inside the app" means lots of things. Just because data is saved to app storage doesn't mean malicious users can't easily access the data. Right, it's just a string field in an object that doesn't get saved. Thanks for the answer. Show nested quote +On October 28 2017 06:12 tofucake wrote:
salting the hash costs next to nothing and is far more secure than not.
you not wanting to salt means you either don't care (bad), don't think it matters (bad), don't want to do it because you don't understand salt (bad, but not as bad as the others), or "need" every possible byte of storage you can get for some other reason (bad)
tl;dr just fucking salt the password It's a proof of concept app(not on the app store) and I didn't want to spend the time implementing it, though I probably will now just for learning's sake. Show nested quote +On October 28 2017 02:40 Blitzkrieg0 wrote:On October 28 2017 02:05 WarSame wrote:
My database is on the phone, so they can't use a rainbow table against it I think. I was thinking more of concerns surrounding passing the hashed value around.
Also, I'm using SHA-256, so I should be fine on that end. The database being on your phone doesn't protect you against a rainbow table. If you have a million users and you hash all the passwords then you're going to have a bunch of duplicate entries in your database as anyone with the same password will have an identical entry after the hash. You add the salt so that each of those will hash to a different value and if an adversary brute forces one password they don't have everyone else's password who was using that same value. Salts protect the collective. They're useless if the adversary is brute forcing one password. The rainbow table is just a list of what common passwords hash to with various algorithms. By utilizing a salt the adversary has to generate a rainbow table for every salt instead of having a master copy. Thanks, I'd misunderstood what a rainbow table actually was and your info makes me a lot more wary of it. EDIT: After more reading, WOW, hashing without salting is awful.
Implementing salt is like 3 steps: generate salt, concat with password when hashing, tack it on to the hashed password
you've spent more time saying you don't want to implement it than it would have taken to just implement it
|
And while at it you could also check out hashing algorithms that are actually good (sha2 is not good any more). pbkdf2, bcrypt, argon2 (listed in order of increasing security). They usually take care of salting for you.
|
On October 28 2017 10:58 phar wrote:
After you have learned, you should then abandon ever doing your own auth scheme by yourself and use oath from something else. Too easy to fuck up. Not quite as hard and fast a rule as "don't roll your own crypto", but still for anything real don't do it on your own. (Fine for this test app)
This is an app to send ethereum peer to peer, so there may be a business reason to avoid OAuth, but if I decide there isn't I'll look into that.
On October 28 2017 20:12 Manit0u wrote:
And while at it you could also check out hashing algorithms that are actually good (sha2 is not good any more). pbkdf2, bcrypt, argon2 (listed in order of increasing security). They usually take care of salting for you.
Yeah I did sha-256 which seems secure.
|
For the app I want to be able to store the user's private ethereum key(if this is stupid/if there is a better way to do it please let me know). I need to be able to store and retrieve, but I want to encrypt it(for security). In order to encrypt/decrypt I need a key. However, that key can't be encrypted(because I need it to do so), so it must presumably be stored in plain text. If I store it in the DB then if they have DB access they can just decrypt. If I store it in a secrets file and they have server access they can just decrypt. What am I missing about this? Is it worth it to encrypt, and if so where do I store this key?
Apologies for my lack of knowledge, but I'm obviously not experience with implementing encryption.
|
First of all, hashing algorithms like bcrypt make several (as in several hundred or thousand even) passes of hashing. They often also store the salt inside the hash (so you only ever need 1 place to store it).
You really should not roll out your own hashing if there are tried and true algorithms that have been battle tested for years.
As a side note: You should never be able to retrieve someone's password (it indicates a weak hashing algorithm). And you should never play around with it in plain text format or use it much in your classes (there's a reason why in Java you should use char array for passwords instead of String).
Typical password flow:
1. User sets their password, you use bcrypt to hash it and store it like that.
2. To validate user password you compare the hashes (you never decrypt your passwords).
3. If the user forgets the password, they have to reset it as you shouldn't be able to decipher them.
|
Can arrays in python only hold basic shit like strings and ints and floats?
If not, how do I create a 2d array filled with objects? In particular, how can I do it if I am only going to actually use *some* of the indexes?
|
Yes, that is what I am currently doing for passwords of accounts in my app. However, I also want users to be able to attach ethereum accounts to their app account. This ethereum account would have a public and private key(as any ethereum account does). I need to retrieve their private key so that they can do ethereum transfers. I suppose I could make them put their private key in every time but that would be tedious.
As I think about this more... is the key to encrypt supposed to just be a password the user remembers?
|
On October 29 2017 12:48 travis wrote:
Can arrays in python only hold basic shit like strings and ints and floats?
If not, how do I create a 2d array filled with objects? In particular, how can I do it if I am only going to actually use *some* of the indexes?
use a list not an array.
avoid premature optimizations. use a list that points to keys in a map if you want to constrain your list size (don't do this, just use a regular list, you don't need this optimization unless you're hitting your hardware limitations and you know what and why you're doing it, in which case you would know to not do this).
|
On October 29 2017 12:48 travis wrote:
Can arrays in python only hold basic shit like strings and ints and floats?
Thats what they say. https://docs.python.org/3/library/array.html
On October 29 2017 12:48 travis wrote:
If not, how do I create a 2d array filled with objects? In particular, how can I do it if I am only going to actually use *some* of the indexes?
Use list? Or perhaps OrderedDict ? I dont know what exactly You want to do and what You need. Anyway i dont think i ever used array in python code oher than during learning.
|
Hyrule19150 Posts
On October 29 2017 02:52 WarSame wrote:Show nested quote +On October 28 2017 10:58 phar wrote:
After you have learned, you should then abandon ever doing your own auth scheme by yourself and use oath from something else. Too easy to fuck up. Not quite as hard and fast a rule as "don't roll your own crypto", but still for anything real don't do it on your own. (Fine for this test app) This is an app to send ethereum peer to peer, so there may be a business reason to avoid OAuth, but if I decide there isn't I'll look into that. Show nested quote +On October 28 2017 20:12 Manit0u wrote:
And while at it you could also check out hashing algorithms that are actually good (sha2 is not good any more). pbkdf2, bcrypt, argon2 (listed in order of increasing security). They usually take care of salting for you. Yeah I did sha-256 which seems secure.
why? out of the 3 manitou listed, you picked something completely different. You're not a crypto guy. You didn't even know what salt was 2 days ago. A rudimentary google search provides no results saying "yeah sha-256 is good"
just use argon2. not using that is negligent
|
Hyrule19150 Posts
On October 29 2017 13:01 WarSame wrote:
Yes, that is what I am currently doing for passwords of accounts in my app. However, I also want users to be able to attach ethereum accounts to their app account. This ethereum account would have a public and private key(as any ethereum account does). I need to retrieve their private key so that they can do ethereum transfers. I suppose I could make them put their private key in every time but that would be tedious.
As I think about this more... is the key to encrypt supposed to just be a password the user remembers?
no
public key cryptography in general uses keyfiles, not passwords. The private key is large and far too cumbersome for a person to memorize. They are stored (with proper file permissions) on disk. For extra security they can be encrypted with a separate password, but most people don't do that
|
Alright cool
Yeah I just ended up using a 2d list. I wanted to use an array for speed of random access. But it looks like python list still has random access of O(1), which is interesting. So I guess lists in python are arrays as well?
|
On October 29 2017 22:01 tofucake wrote:Show nested quote +On October 29 2017 02:52 WarSame wrote:On October 28 2017 10:58 phar wrote:
After you have learned, you should then abandon ever doing your own auth scheme by yourself and use oath from something else. Too easy to fuck up. Not quite as hard and fast a rule as "don't roll your own crypto", but still for anything real don't do it on your own. (Fine for this test app) This is an app to send ethereum peer to peer, so there may be a business reason to avoid OAuth, but if I decide there isn't I'll look into that. On October 28 2017 20:12 Manit0u wrote:
And while at it you could also check out hashing algorithms that are actually good (sha2 is not good any more). pbkdf2, bcrypt, argon2 (listed in order of increasing security). They usually take care of salting for you. Yeah I did sha-256 which seems secure. why? out of the 3 manitou listed, you picked something completely different. You're not a crypto guy. You didn't even know what salt was 2 days ago. A rudimentary google search provides no results saying "yeah sha-256 is good" just use argon2. not using that is negligent
I knew what a salt does(in general) the whole time. My particular question was whether you needed to do it when you had a SQLite database on each phone. I'd forgotten how rainbow tables worked. I'll look into the other algorithms, but I picked SHA-256 based on some articles I was reading which suggested it.
On October 29 2017 22:04 tofucake wrote:Show nested quote +On October 29 2017 13:01 WarSame wrote:
Yes, that is what I am currently doing for passwords of accounts in my app. However, I also want users to be able to attach ethereum accounts to their app account. This ethereum account would have a public and private key(as any ethereum account does). I need to retrieve their private key so that they can do ethereum transfers. I suppose I could make them put their private key in every time but that would be tedious.
As I think about this more... is the key to encrypt supposed to just be a password the user remembers? no public key cryptography in general uses keyfiles, not passwords. The private key is large and far too cumbersome for a person to memorize. They are stored (with proper file permissions) on disk. For extra security they can be encrypted with a separate password, but most people don't do that
Right, I don't expect them to memorize their private key. But if our security stuff is based off the assumption that they can get access to our DB, how is it any more secure to encrypt with a keyfile if they could get access to that, too? Are we just making the assumption that if they have access to both of those then we're fucked?
|
General workflows for this sort of thing:
1) blob of whatever you're going to store exists on client
2) use client-known password as key to encrypt
3) send server encrypted blob for storage
4) never decrypt on server
5) new client can retrieve and decrypt blobs they know password for
6) issue any queries you need from client, not server
Or
1) have an existing storage that you can secure on server side
2) use this to store credentials
3) now you can decrypt on server side.
Hard to say without knowing your architecture.
And again a plea to not hook this up for real to anyone's actual money (just doing it as a test thing is fine). Don't roll your own crypto, probably don't roll your own security.
|
I don't know why you guys say sha-256 isn't safe. I'm not aware of any collision or pre-image attack that is successful but if you have a reference I'm very interested.
If people use a crypto wallet on their phone, they must assume that it can be stolen. That's just trade-off between convenience and security. A wallet can be more secure than cash though. What you do (and any good wallet does), is encrypt the private key with AES256 with another key which is obtained from applying a key stretching algorithm such as pkdf2 on the short password or pin that the user must provide in order to unlock his wallet. After a few failures, your app can even delete all the keys.
The only way for an attacker to get access is to root the phone, grab the encrypted passwords and try every pin number. With a good key stretching algo, he should be occupied long enough for the rightful owner to use his backup on another device and transfer everything to a new account.
|
On October 29 2017 12:14 Manit0u wrote:
First of all, hashing algorithms like bcrypt make several (as in several hundred or thousand even) passes of hashing. They often also store the salt inside the hash (so you only ever need 1 place to store it).
You really should not roll out your own hashing if there are tried and true algorithms that have been battle tested for years.
As a side note: You should never be able to retrieve someone's password (it indicates a weak hashing algorithm). And you should never play around with it in plain text format or use it much in your classes (there's a reason why in Java you should use char array for passwords instead of String).
Typical password flow:
1. User sets their password, you use bcrypt to hash it and store it like that.
2. To validate user password you compare the hashes (you never decrypt your passwords).
3. If the user forgets the password, they have to reset it as you shouldn't be able to decipher them.
Is my app secure? I store the passwords in plain text in MySQL database.
This is true. I do exactly that. But security is far far far less important than being able to tell 12-yo kids what password they used to register. And resetting 5-10 passwords every class would just take way too much time.
|
Hyrule19150 Posts
On October 30 2017 00:01 WarSame wrote:Show nested quote +On October 29 2017 22:01 tofucake wrote:On October 29 2017 02:52 WarSame wrote:On October 28 2017 10:58 phar wrote:
After you have learned, you should then abandon ever doing your own auth scheme by yourself and use oath from something else. Too easy to fuck up. Not quite as hard and fast a rule as "don't roll your own crypto", but still for anything real don't do it on your own. (Fine for this test app) This is an app to send ethereum peer to peer, so there may be a business reason to avoid OAuth, but if I decide there isn't I'll look into that. On October 28 2017 20:12 Manit0u wrote:
And while at it you could also check out hashing algorithms that are actually good (sha2 is not good any more). pbkdf2, bcrypt, argon2 (listed in order of increasing security). They usually take care of salting for you. Yeah I did sha-256 which seems secure. why? out of the 3 manitou listed, you picked something completely different. You're not a crypto guy. You didn't even know what salt was 2 days ago. A rudimentary google search provides no results saying "yeah sha-256 is good" just use argon2. not using that is negligent I knew what a salt does(in general) the whole time. My particular question was whether you needed to do it when you had a SQLite database on each phone. I'd forgotten how rainbow tables worked. I'll look into the other algorithms, but I picked SHA-256 based on some articles I was reading which suggested it. Show nested quote +On October 29 2017 22:04 tofucake wrote:On October 29 2017 13:01 WarSame wrote:
Yes, that is what I am currently doing for passwords of accounts in my app. However, I also want users to be able to attach ethereum accounts to their app account. This ethereum account would have a public and private key(as any ethereum account does). I need to retrieve their private key so that they can do ethereum transfers. I suppose I could make them put their private key in every time but that would be tedious.
As I think about this more... is the key to encrypt supposed to just be a password the user remembers? no public key cryptography in general uses keyfiles, not passwords. The private key is large and far too cumbersome for a person to memorize. They are stored (with proper file permissions) on disk. For extra security they can be encrypted with a separate password, but most people don't do that Right, I don't expect them to memorize their private key. But if our security stuff is based off the assumption that they can get access to our DB, how is it any more secure to encrypt with a keyfile if they could get access to that, too? Are we just making the assumption that if they have access to both of those then we're fucked?
"I temporarily forgot how salt works" is the same as not knowing how salt works. Maybe you learned it before, but you don't know it.
And because keyfiles are stored on disk and not in a database, and have different security. So even if an account is compromised, the keyfile is still safe. You assume both are, but you make it as difficult as possible to get both with 1 attack (e.g., don't store the keyfile in the database)
|
On October 30 2017 01:23 phar wrote:
And again a plea to not hook this up for real to anyone's actual money (just doing it as a test thing is fine). Don't roll your own crypto, probably don't roll your own security.
But how?!? If I could get away without doing this, and also make it more secure I would love to do that. Or are you talking about just hiring someone for the security side of things?
|
|
|
|
|
|
EPT
