Get mapKey() of single map element?

[doctorized]

To answer all questions, I make an app that stores school grade data in a db. There is a table with the grades with the following coloumns: id of student, lesson tinyint, grade char(2), date, grade_type (oral, test), grade weight (for the average grade). Lesson's names (in Greek) are from 6 to 45 bytes long. I do not want every row to have lesson as char because:
1) db size will become too big after 2-3 years
2) if someone finds the db and tries to take a look at the data, I do not want to find out many things. I will try to use sql cipher at some point in the future.
That's why I use numbers, 1 to 13 for the lessons in the base. That's why there are no duplicates. I use the lessons' names just to show them in the views when the user wants to see them.

[NicTheQuick]

If really someone get his/her hands on the database taking a look at the data is your smallest problem. Don't encrypt the data inside the table. Encrypt the database itself.

If you want to create a database schema which is future proof, read that article of Database normalization on Wikipedia.

[skywalk]

This is a design issue for you to decide pros and cons.
Encrypting the entire database requires managing access with usernames and passwords, which is another database or table in the database. Once the password is shared or stolen, the database is wide open.
Encrypting columns you deem sensitive means your app is the only way to extract data.
But, your queries are garbage on cryptic columns until decrypted.
My preference for sensitive databases is allowing them to exist anywhere in the open, but my app is the only way to decipher.

[doctorized]

Once the password is shared or stolen, the database is wide open.

That's why I am about to save SHA version of username and password, and not the username/password itself. Only my app will be able to use the credentials. Which is better, SHA-1, SHA-2 or SHA-3? 256 or 512 bits?

[NicTheQuick]

Once the password is shared or stolen, the database is wide open.

That's why I am about to save SHA version of username and password, and not the username/password itself. Only my app will be able to use the credentials. Which is better, SHA-1, SHA-2 or SHA-3? 256 or 512 bits?

I don't understand why you want to hash the username. And of course you have to use hashes for password. if you save passwords as plain text you will get fired because of stupidity. Use an established hash algorithm for passwords. You can read a lot about that topic online. A quick google search gave me this: https://security.stackexchange.com/ques ... -passwords

[doctorized]

I don't understand why you want to hash the username. And of course you have to use hashes for password. if you save passwords as plain text you will get fired because of stupidity. Use an established hash algorithm for passwords. You can read a lot about that topic online. A quick google search gave me this: https://security.stackexchange.com/ques ... -passwords

I should not hash username? Why not? I know it doesn't offer anything but... why not?
I hash credentials in every project. I use SHA-3 512, just because it is the greatest one. That is why I asked if I should use SHA-1, SHA-2 or SHA-3.

[NicTheQuick]

I don't understand why you want to hash the username. And of course you have to use hashes for password. if you save passwords as plain text you will get fired because of stupidity. Use an established hash algorithm for passwords. You can read a lot about that topic online. A quick google search gave me this: https://security.stackexchange.com/ques ... -passwords

I should not hash username? Why not? I know it doesn't offer anything but... why not?
I hash credentials in every project. I use SHA-3 512, just because it is the greatest one. That is why I asked if I should use SHA-1, SHA-2 or SHA-3.

I didn't said you should not hash the username. I simply don't understand why. You would never know which users are in your database at all if you can only see the hash of it. But if you want to do it, there is nothing what would make it less secure.
SHA-3 512 is a good one I guess. But in general there often is more to do. At least a good salt would be a great thing. The next simple thing would be to hash the password mulitple times. And there is pepper. But you can read about all of that in the link on stackexchange.

[skywalk]

Nothing wrong with obscuring usernames, but a simpler crypt method(xor+your secret) is enough to dissuade prying eyes. You are not asking the user for a username secret and a secret password.
Your app only asks for their secret password to then compare with stored SHA-xyz hashes.
If a match, then user can proceed.

[doctorized]

Nothing wrong with obscuring usernames, but a simpler crypt method(xor+your secret) is enough to dissuade prying eyes. You are not asking the user for a username secret and a secret password.
Your app only asks for their secret password to then compare with stored SHA-xyz hashes.
If a match, then user can proceed.

Call me urnal but, at first I xor credentials using a code found somewhere here in this forum using a 512bit hex key (values 0 to 255) and after that I hash SHA-3 512 the xor result. Stolen credentials are useless without my app.