Db.PNG

db.PNG


constructive criticism

Other urls found in this thread:

youtube.com/watch?v=8ZtInClXe1Q
en.wikipedia.org/wiki/Relational_database
docs.oracle.com/javase/tutorial/jdbc/overview/database.html
youtube.com/watch?v=NvrpuBAMddw
rot26.org/
twitter.com/SFWRedditGifs

Turn the whole thing on its head.

Let each "subclass" of Product have a foreign key referencing Product.

ABSOLUTE SHIT

>password

That better be a bcrypt hash son.

THIS.

"[username] [salt] [password] [userType]" or into the trash it goes.

youtube.com/watch?v=8ZtInClXe1Q


One thing I don't understand is how you make sure at which table you have to look for a certain product? I take it that "description" contains the name of the table of the product details (i.e. "CarAdapter")? Maybe you need a better name here.

The most important part is that "Product" has the primary key. Therefore you can make a new table "Orders" which is just a "n:n"-relationship from "Customer" to "Product". Orders might contain the fields "Quantity", "Date" and maybe "Status" ("ordered", "delivered" and so on). Just make sure to have a well-defined point where you reduce the quantity of "Product".


Just my 2 cents..

>storing the salt separately from the hash
why?

what is this and how do i learn it? it looks cool

For each user you generate a new (random) salt. So the field "password" in your table doesn't contain the real password, but the salted hash. If you do it right there should be no way that YOU know which password the user used if you just have the table.


So what when he is trying to log in?
Say "user_1" logs in with "my_password", you need to do the following:

$user_name = "user_1" (-> from the login screen)
$password_login = "my_password"
$password_db = "3812fw)/§$vsj$%789sgn39§$17" (from your database)
$salt = "s$g356§lsvd324ihsdvsdo864gdf"

if ( sha-1( $password_login + $salt ) == $password_db ) {
// access permitted
} else {
// access denied
}

I'm aware how salts work but you can just store the salt in the same db string as the hash. that's how php's function does it.

Relational Databases.
>en.wikipedia.org/wiki/Relational_database
>docs.oracle.com/javase/tutorial/jdbc/overview/database.html

youtube.com/watch?v=NvrpuBAMddw

>oracle
please don't

>SQL
Why are you using depreciated database? Cool kids use nosql document db

Oh I see.

Yes you could do this, both ways work just fine.

Also you'd best have been using sha1 for the example only. I'll hunt you down otherwise.

If you're trying to be edgy, at least get your grammar right..

It's just a general introduction, no need to get butthurt.

Oh, but you are sure that you don't confuse it with "pepper"? The important part is that salt gets add BEFORE the hashing, so if you want to save it in one string, you need to split the string and get the salt, to use it with the plain text password. Therefore it makes sense to me to put it in a single field, since you need to extract it anyway.

MongoDB does have some impressive benchmarks, but they do some interesting things to get those numbers. For example, when you write to MongoDB, you don't actually write anything. You stage your data to be written at a later time. If there's a problem writing your data, you're fucked. Does that sound like a good design to you?

Of course!

In really I use MD-5..

:^)

to my knowledge bcrypt stores the salt and hash in the same string that you then split when verifying.

i use rot13

*in reality

>bcrypt stores the salt and hash in the same string that you then split when verifying.

Correct, that makes things easier to process. Not so many things where the user can fuck it up. But this is totally unnecessary when we use MD-5 or rot13.

>not getting adrenaline rush from living on the edge, always waiting to get exploited

BTW my password tables are all just a honeypot. As soon as someone steals them and usese them, a complicated mechanism start that logs him and tries to trace him back.

The REAL passwords are in a table called "DEPRECATED_db_config_old". Fuck you, Kerckhoff.

>mvarchar all the things
stopped reading there, assume this is a troll

>i use rot13
I love rot13. In fact, I encrypt all of my Sup Forums posts, including this one, using rot13. Twice, for good measure.

user we can't understand this encrypted post, please post the original unencrypted text.

Is [salt] random generator?

As i understand, user inserts his password, that string gets hashed, you end up with shitload of characters, insert salt random characters in random places and then store the password in your database?

How do you know what characters are random and which ones are salt? I am total noob, just learning programming as a hobby

Nope, you add the salt to the password, then hash everything.

For example: "dsa123da" + "password123" -> "3bcc8e903917de79487178da20d76a5ce23f19"

>As i understand, user inserts his password, that string gets hashed, you end up with shitload of characters, insert salt random characters in random places and then store the password in your database?
What the shit user. No. here's a simple method of salting (not a good method to use in practice, but sifficient for demonstration)

salt = generate_secure_random_string()
result = hash(hash(password) ++ salt)


Store ‘result’ and ‘salt’ in your database. When a user enters a password, verify it by repeating the same procedure (with the stored salt instead of the generated salt).

if i want to create a product using preparedstatemnt

you add the salt BEFORE hashing, when the original hash is generated and placed in the database and then later when you are verifying the hash. the simplest way would be to just concatenate the salt to the password before hashing.

>people that unironically use mongoldb
>mfw

how do i create a battery for example

But isn't storing salt as a string unsafe if someone takes your database? Judging from that Computerphile's vid when people steal your hashes you're fucked. Not plaintext fucked, but still fucked

>double hashing
why

the idea of salting is to stop rainbow table attacks. the only real way to stop someone that has access to your database is to use an intensive hashing algorithm so it would be infeasible to hash every entry.

answer me faggots

nobody knows what the fuck you're asking

Oh, i see now

What algorithm people use nowadays, md5 and sha1 are broken afaik?

Does the choice of algorithm affect performances in big databases?

Yeah never mind that, double hashing is only important for MACs, since given a known-plaintext you could construct a length extension that way.

But for passwords, if you have a known plaintext already, you already have all the information you need - ergo it doesn't matter. Single hashing should be fine.

>But isn't storing salt as a string unsafe if someone takes your database?
Understanding the benefits of a salt is impossible when considering only a single account.

Try thinking about an entire database of accounts, many of which will share the same password in common. Using a salt, even if that salt is public, prevents the attackers from knowing which users have passwords in common. It also prevents them from applying a brute force attack to all accounts simultaneously (since you need a different salt per user).

bcrypt is the current gold standard, but there are promising ones that afaik aren't audited yet.

as for performance, more intensive algorithms are general better as the idea is to sacrifice speed for security.

>What algorithm people use nowadays, md5 and sha1 are broken afaik?
The status quo is to use sha256, and perhaps sha512 if you're exceptionally paranoid; but we should be transitioning to sha3 as soon as it's mature.

no, sha256 is definitely not good enough. it's bcrypt or nothing.

bcrypt is not really a hash function, it's a domain-specific function for storing passwords

My comment was about hash functions used in general (since user asked about md5 and sha1, which are both also regular/fast hash functions)

rot26.org/

Does MS Sqlserver has already built in salt generator in it? You generate new salt for every user, right? Anything else wouldn't make any sense

I agree that bcrypt is the one and only thing you should use right now.

Nevertheless, we must not forget that hashing algorithms are often considered "unsafe" because some extraordinary skilled guy managed to somehow did something. It generally does NOT mean the average J.Hacker could pull this off, it does not mean he could actually do something. But it's better to be safe than sorry.

yes, new salt for every user.

dunno about ms sqlserver, sorry user.

>he doesn't store his passwords in reverse Al-bhed.

Y'all smalltime fags needa grow-up.

These real nigga incryptz

>he doesnt make his tables dynamically encrypts per minute everything including the table name

its like you want your database to be hacked

>he uses databases on a computer instead of having a notepad with user data and knowing each user individually so you can verify who they are when they call you asking to access their account
it's like you're not true webmasters

Yes, you generate a seperate salt for each user.
See: Generally databases don't care what you store in them. It's called "seperation of concerns".

It's up to the programmer to decide for a security concept.

On a serious note, how much does the encryption affect database queries?

This reminds me, i have a friend working in medium sized company, one central location and ~50 small branches (1-2 pcs max in each). He complains how his database queries to central server are slow as fuck, several seconds slow. Could that be encryption, or just very shitty internet speed (that was my guess before this thread)

The problem with bcrypt is that what you save in leak-resistance you trade off in vulnerability to DoS.

bcrypt is by design very expensive to compute, so a user spamming your website with login requests can easily overload your computational capacity and prevent legitimate users from logging in

bank employee from switzerland detected..

Which is why you have fail-safes like maximum login attempts and blocking IPs or even entire IP ranges.

or captchas to login but that's a bit silly

>correcting grammar on the internet

Either you have some small scale defense measures like this user said: Or for bigger attacks it's a game of who has more hardware. I mean they even took down each single wikileaks server right before the US election. No matter how much defense you have, if the attacker is big enough you lose.

Last but not least, it's much better to be unavailable for some hours or even days than to lose customer data.

What do you do if users login only once and then send shitload of legit queries to server, and then you get compromised and receive spam queries, how do you defend from that?

What is your goal? Kinda hard to determine how good/bad it is with just the ER diagram

So whenever someone tries to log in, you do the procedure with every salt until it finds the correct one?

afaik you create procedure where it compares login and hash (plaintext password + salt for that password)

Can someone explain foreign keys in retard-friendly way? Primary keys are understandable, but i don't get foreign keys

As i understand, foreign keys are used to make exact matches with primary key column, so when someone updates the database you insert new row into all tables with the same purchase_ID for example, am i right?

bump

unless you don't use email confirmation/captcha etc. the attacker most likely won't have legitimate accounts, at least not many.

Imho it would be best to use something like Active directory/domain controller, so you actually see who logins and where

Google it shitlord

Someone explain this to me. IF you store the salt in the same db than the password then doesn't that makes it useless. You have to assume the hacker who got the hash passwords also got the salt. Shouldn't the salt be stored as far as possible from the hash password?

If hackers get hashed passwords they stil don't know they plaintext, they use rainbow tables to find a word that gives the same hash (if they use md5 for example). Now, if you add random generated salt into hash your end up with hashes that are in no one's rainbow table, so hackers can't do shit, even if they know plaintext salt.

Why do you have so many instances of typeID? Each table needs its own unique identifier. Also, storing typeName in each table opens up the possibility for more errors, in addition to being a waste of storage space.

How would you change it?

Ok so salt is a tool against rainbow tables but not against brute force cracking. Right?

The salt just ensures that if someone finds the hash for a certain password, everyone who uses that same password can't be found by doing a simple ctrl+f("hashedpassword").

In a case where there's a lot of users, there's probably going to be a few who use Chris123 as their password.

yeah, but brute force cracking sha512 for example is really NSA-tier brute forcing, so you're pretty much safe against everyone except government

No? You know the salt for that user..

Salt is a tool against rainbow tables, mass cracking and password comparison attacks

No it isn't. sha512 is still very fast to compute.

>constructive criticism
It's not a Nassi-Shneiderman chart.

>constructive criticism
It doesn't use crows foot notation.

Is it webscale?

What are these things?

constructive criticism