UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

#1 2010-08-03 04:19 PM

RipRage
Member
From: England
Registered: 2010-01-06
Posts: 146

Re: Creating a database

Dear experts
I would like to add a register/login feature to my program. I will be very grateful if anyone can give me hints on how i can create a secure database to store the users login information. the simple code below just stores the information in a file. witch of course is not a good method unless I use some sort of encryption...

#include <stdio.h>
#include <string.h>

struct user_info {
	char user[30];
	char pass[30];
};

int main()
{
	FILE *fp;
	struct user_info store;
	int a, b;

	printf("Please enter a username: ");
	gets(store.user);
	printf("Please enter a password: ");
	gets(store.pass);

	while (1) {
		a = strlen(store.user);
		if (a >= 5 && a <= 15) { 
			b = strlen(store.pass);
			if (b >= 5 && b <= 15) {
				printf("Creating account....\n");
				break;
			} else {
				printf("Please enter a password using characters between 5 and 15!\nTry again: ");
				gets(store.pass);
				continue;
			}
		} else {
			printf("Please enter a username using charcters between 5 and 15!\nTry again: ");
			gets(store.user);
			continue;
		}
	}

	if ((fp = fopen("User.dat", "w")) == NULL) {
		printf("Failed to create account!\n");
		return 1;
	} else {
		fprintf(fp, "User: %s\tPass: %s\t", store.user, store.pass);
		fclose(fp);
	}

	printf("Account has been created.....\n\n");

	return 0;
}

Looking forward to your replys :)

Offline

#2 2010-08-04 02:13 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,205

Re: Creating a database

You shouldn't store the passwords as given, nor encrypted. Instead you should
hash them together with the username and a salt in a secure way. After that
it doesn't really matter how you store it, as it doesn't contain any sensitive
information.

Don't use MD5 or SHA-1.

Offline

#3 2010-08-11 03:00 PM

RipRage
Member
From: England
Registered: 2010-01-06
Posts: 146

Re: Creating a database

Thanks for your reply. I'm still not sure how i would do that, would i need to create a function witch hashes the 2 strings together and a simple fprintf() into a file to store them? i imagine i would need to create a second function to decrypt the hashes back to a readable string? if anyone can suggest more information on hash functions and how they work, i will be most grateful. would like to grok them!

Many thanks

Offline

#4 2010-08-11 07:58 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,205

Re: Creating a database

The whole point of hashes is that you can't know the original value, they're
one way.

A salt is just some random number (e.g. creation time of the account) to
thwart dictionary attacks, in case your server gets compromised.

At account creation time, store the username, make up a salt value and store
hash(username + salt + password), where + is string concatenation. So
hash the whole combination once, not separately.

When someone tries to log in, check if that user exists, look up their salt value,
calculate hash(username + stored salt + supplied password). If it's equal to
the stored number then the password was correct, otherwise it was incorrect.

As usual, Wikipedia has reasonable information:
http://en.wikipedia.org/wiki/Cryptograp … h_function

Offline

#5 2010-08-11 08:12 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,769
Website

Re: Creating a database

i imagine i would need to create a second function to decrypt the hashes back to a readable string?

No, for passwords you want to use a one-way hash...  The way you verify the
password is correct later is to perform the same hashing procedure again on the
newly user-entered password and compare that result with the hash you have
stored on disk...  Ie: just exactly like the standard Unix password stuff has always
worked...  (Just that historically it has used a rather weaker DES-based hash and
stupidly limited the passwords to 8 chars at max, while modern versions allow use
of MD5, SHA*, Blowfish, and/or other methods of creating the password hashes,
and they don't limit the password length arbitrarily...)  In fact, there's no reason you
couldn't simply use your system's native crypt() function, if it supports one of the
better hashing methods (typically indicated by prefixing the salt with "$<#>$"; eg.
"$1$" generally indicates MD5 hashing)...  You'll probably also want to still make the
file you store the password hashes to only readable by the UID of the process
that's going to do the password verification...  Otherwise, people might be able to
crack the passwords with an offline dictionary or brute-force attack on their own
machines...  (That's the reason for the separate root-readable-only "/etc/shadow"
on modern Unixes, instead of storing the hashes directly in world-readable
"/etc/passwd", as in the old days...)

And, I'm going to go ahead and disagree with i3839: I think using MD5 for password
hashing is fine...  The well-known collision weaknesses are really only useful for
attacks on things that use the hash as an integrity checking measure of some kind,
allowing you to construct a malicious duplicate with the same hash such that it can
masquerade quietly as the original...  Eg: SSL certs or tripwire-like file integrity
checking...  In these cases, the hash is widely distributed and well-known to start
with; with password hashes, you first have to break in and somehow gain access
to read the password database...  Then, you have to contend with the fact that
password hashing uses MD5 in a different way than simply hashing the password
in a straightforward manner (go read the source for an MD5-based crypt() sometime;
it's a truly twisted thing to behold), and it throws in a salt...  I don't think the collision
weaknesses can really buy you much advantage as far as being able to deduce a
password that produces the same hash... *shrug*

Offline

#6 2010-08-11 08:20 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,769
Website

Re: Creating a database

A salt is just some random number (e.g. creation time of the account) to
thwart dictionary attacks, in case your server gets compromised.

It's more to thwart rainbow tables, really...  If they've gotten access to the hashes,
then they also have the salts, and can still perform a simple offline dictionary attack
to crack any weak passwords in use...  (And, of course, they can always perform
an online dictionary attack directly against your login server, if you don't thwart that
somehow, as well...)

Offline

#7 2010-08-11 09:03 PM

RipRage
Member
From: England
Registered: 2010-01-06
Posts: 146

Re: Creating a database

Holy cow! that's alot to take in for a self learner like myself hehe :-) but thank you guys your knowledge is increadble. You have now given me a notation, now for me to convert it to code :-)

Thanks again

Offline

#8 2010-08-11 10:38 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,205

Re: Creating a database

RobSeace;30339 wrote:

It's more to thwart rainbow tables, really...  If they've gotten access to the hashes,
then they also have the salts, and can still perform a simple offline dictionary attack
to crack any weak passwords in use...  (And, of course, they can always perform
an online dictionary attack directly against your login server, if you don't thwart that
somehow, as well...)


Yeah, I only had pre-computed dictionary attacks in mind. They can do the plain
dictionary one via the login form too.

MD5 might be fine in practise now, but the sooner the habit of using it is broken
the better. You have to think 10 to 20 years ahead with these things. :-)

Offline

#9 2010-08-12 01:20 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,769
Website

Re: Creating a database

MD5 might be fine in practise now, but the sooner the habit of using it is broken
the better. You have to think 10 to 20 years ahead with these things. :-)

I certainly agree that using just plain old MD5 for any security purposes these days
seems shortsighted and dangerous...  But, my point was that MD5-based crypt() is
far more than just a simple MD5 hash of the password...  If that's all it was, then I'd
fully agree with you that no one should use it...  But, honestly, go read the source for
MD5 crypt(): it hashes together the password, the salt, a HASH of the passwd+salt+password,
a mix of zeros and the first char of the password based on the length of the password,
and then a bizzare mix of the hash computed so far to this point, the original password,
and the salt, all repeated 1000 times in a loop...  It's fucking twisted...  And, I really
don't think any simple MD5 vulnerability is going to help you at all untwist that mess
of multiple hashes of hashes of hashes...  Even if there were a simple one-shot
guaranteed way to produce text with any arbitrary given MD5 hash value, it wouldn't
help you one bit in producing the correct password for a given MD5 crypt() hash...
The strength or weakness of MD5 itself is pretty much totally irrelevant given the way
it's used (or abused) in crypt(), IMHO...  The only thing you need to worry about is
how fast it runs on modern hardware, which limits how fast one can brute-force
crack your passwords by just trying the same twisted algorithm on every possible
sequence of characters...  (But, given that MD5 crypt() doesn't limit password length,
then that also becomes impractical, given sufficiently long passwords, regardless of
how fast the crypt() process itself is...)

Offline

#10 2010-08-12 04:05 PM

RipRage
Member
From: England
Registered: 2010-01-06
Posts: 146

Re: Creating a database

OK guys, iv been looking at hash functions for an hour or so this morning, and I thought I would have a go at making my own... To keep this simple I haven't included a salt (that's the next stage) instead I have just based it on the old RSHash function, so I can understand the notation of hashing the user-name + password together in code :-)... also stuck on a windows machine at this current time so no crypt() function witch I believe is only Unix based...

here it goes...

/* My first hash function */

#include <stdio.h>
#include <string.h>

// Create a function witch hashes username & password together

int hashit(char *str1, char *str2, unsigned int len) 
{
	unsigned int b = 378551;
	unsigned int a = 63689;
	unsigned int hash = 0;
	unsigned int i = 0;

	for (i = 0; i < len; str1++, str2++, i++) {
		hash = hash * a + (*str1) + (*str2);
		a = a * b;
	}

	printf("The hash is: %u\n", hash);

	return hash;
}

// Main

int main()
{
	char user[30];         // Username
	char pass[30];         // Password
	int ulen, plen, total; // Length of username + password

	printf("Hash test...\n");

	printf("\nPlease enter a username: ");
	gets(user);
	printf("\nPlease enter a password: ");
	gets(pass);

	// Check character length on input

	while (1) {
		
		ulen = strlen(user);
		
		if (ulen >= 5 && ulen <= 10) {
			
			plen = strlen(pass);
			
			if (plen >= 5 && plen <= 10) {
				
				total = ulen + plen;
				
				printf("\nDisplay results...\n\nUser: %s\tUser_len: %d\tPass: %s\tPass_len: %d\tTotal: %d\t\n\n", // Show results
					user, ulen, pass, plen, total);
				
				hashit(user, pass, total); // Hash the strings
				
				break;

			} else {
				
				printf("\nPlease enter a password using charcters between 5 and 10!\nTry again: ");
				gets(pass);
				continue;
			}
		} else {
			
			printf("\nPlease enter a username using charcters between 5 and 10!\nTry again: ");
			gets(user);
			continue;
		}
	}

	getchar();

	return 0;
}

Output....

Hash test...

Please enter a username: Daniel

Please enter a password: hashing

Display results...

User: Daniel    User_len: 6     Pass: hashing   Pass_len: 7     Total: 13


The hash is: 4225718179



It Works... Looking forward to hearing your great knowledge once again :-)

Offline

#11 2010-08-12 07:22 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,769
Website

Re: Creating a database

A 32-bit hash value is horribly small for this sort of use...  Old-school Unix DES-based
crypt() uses 56-bits, which is already considered too small and easily crackable by
brute-force...  MD5 is 128-bit...  That should probably be your absolute lower bound,
especially if rolling your own password hashing algorithm on top of it...

But, surely, Windoze libraries can be obtained to do proper hashing for you?  There
exist several free MD5 libraries you could surely port and use...  And, there are also
libraries of multiple different hash functions...  Rolling your own actual hash function
is probably a really horrible idea...  It's almost guaranteed to be less secure than any
of the standard widely used algorithms...

Rolling your own password-hashing algorithm on top of a known hashing function
is a different matter, though...  That's not so bad, as long as you do it right...  You
probably want to do more than just a simple direct single hash of the password (plus
salt and/or username or whatever), though...  See the MD5 crypt() source for an
idea of the sort of twisted tricks you may want to add to make sure the end resulting
hash is truly irreversable, and even if your chosen hashing algorithm is flawed, that
the password can't easily be obtained from it...  Plus, you'll want to just do a bunch
of stuff repeatedly to burn up time, so you don't run too fast, which would allow fast
brute-forcing...

Also, as a side-note, you have a bug there, in that you run off the end of both
strings you're hashing, adding pseudo-random junk off your stack into the hash
value, which will likely end up producing different hash values for the same input
on different machines or just different processes on the same machine...  You add
both lengths together, and take that many bytes out of BOTH strings...  You need to
pass both lengths separately and only take as many out of both as there are...

Offline

#12 2010-08-13 11:43 PM

RipRage
Member
From: England
Registered: 2010-01-06
Posts: 146

Re: Creating a database

You add
both lengths together, and take that many bytes out of BOTH strings... You need to
pass both lengths separately and only take as many out of both as there are...

Yup, i realised that, major error, silly me  :-(... For the mean time i am using some windozes functions witch handles all the hashing. i want this application to work over a socket starting with the registration, if you guys can help me grok how to do this i will be very grateful ;-). I gather i start with the client prompting for the username and password, followed by the hashing process, then connect()ing to the server, send()ing the hash, Server recv()'s the hash open()'s a file (were the hashes are stored, to keep it simple for now) checking to see if any previous hashes exist witch are equal(username and password already exist) if false fprintf() hash to file, send() ack back(account has been created) close() socket etc, else send() username and password already exist try something else....

is this correct?

looking forward to your reply :-)

Offline

#13 2010-08-14 07:13 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,769
Website

Re: Creating a database

then connect()ing to the server, send()ing the hash

No, this is a bad idea...  Then, an attacker doesn't even need to do anything to
crack your hashes: all they need is to obtain the hashes, and just send them as-is,
and you let them in...  Ie: you're just turning the raw hashes into the true passwords
now, and this would be exactly equivalent to storing the plaintext passwords on
disk to start with...  Plus, unless you're using an SSL connection, they can just
sniff the hashes off the wire, without even needing to break into the server to obtain
them from the file...

You need to let the hashing happen on the server side...  In fact, if you're using a
salt, there's not even any way the client could possibly do the hashing, since it won't
know what salt was used to create the original hash...  Of course, this means you
need to send the plaintext password, as typed, over the wire, which itself is dangerous,
too...  So, you really should be using SSL (or something else) to encrypt the connection
as well...

Offline

#14 2010-08-14 07:43 PM

RipRage
Member
From: England
Registered: 2010-01-06
Posts: 146

Re: Creating a database

Damn it! I know all this, I'm annoyed with myself for even thinking of that notation in the first place :-(... Oh well back to the drawing board, need to look up and see if windoze have any functions for creating ssl sockets...

Offline

#15 2010-08-15 10:43 AM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,205

Re: Creating a database

Well, it's not such a bad idea for account creation, because then it doesn't
really matter. It's just that for every login after that you have to do it the
conventional way of sending the username + password, so you're only making
the implementation more complicated.

But if you never want to send the plain password then you can do double
hashing, with the client sending a hash, and the server hashing that again
with its salt added. If you want the client to be stateless but still protect a bit
against pre-computed dictionary attacks, then use always the same salt for the
client hashing. E.g. hash username + fixedsalt + password on the client, and
just username + clienthash + salt on the server.

Offline

#16 2010-08-15 04:43 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,769
Website

Re: Creating a database

need to look up and see if windoze have any functions for creating ssl sockets...

There's a Windoze port of OpenSSL...

But if you never want to send the plain password then you can do double
hashing, with the client sending a hash, and the server hashing that again
with its salt added.

But, really, that doesn't buy you any real protection, either...  Because, the only thing
you're protecting against is sniffing of the plaintext password on the wire, and in this
scenario they no longer even need the plaintext password: instead, they can just
sniff the intermediate hash off the wire, and retransmit that instead, and it's exactly
the same as if they had sniffed the plaintext password since it functions identically...

The only way something like that would really work is if each client had to create a
unique hash value which would be useless for replaying by anyone else that happened
to sniff it...  But, such a scheme couldn't really work where you need to rehash the
hash and produce a single end result...  Instead, you'd probably need to go with a
challenge/response type setup: the server generates some random data and sends
it to the client; the client hashes that along with the entered password, and sends
back that hash; the server would then need to be storing the plaintext passwords
in order to compute the same hash locally and verify the client's hash is correct...
Alternatively, the server could still keep storing the password hashes locally, and
send the client the current salt used along with the random data, and then the client
could compute the same hash that the server has stored for the password, and
then it could hash together that hash along with the random data to produce the hash
to send over the wire...  Of course, that's really no more secure than having the
server store the plaintext passwords locally, even though it might seem to be...
Because, if the server is compromised and the password hashes are stolen, then
the cracker has all they need to login as anyone, since they can now answer the
challenge just as easily even without knowing the real password, since all they need
is the hash (which they have) to go along with the sent random data...  So, either way
you slice it, the file of passwords/hashes on the server becomes the weak point in
such a scheme, though you do defend against sniffing attacks on the wire...  Personally,
I'd just go with SSL or some other type of encryption to defend against the sniffing,
and just send the plaintext passwords over the encrypted channel to the server,
which keeps the server-side file of password hashes dumb, and would require an
attacker to still crack them into real passwords first before being able to use them...

Offline

#17 2010-08-16 01:36 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,205

Re: Creating a database

RobSeace;30364 wrote:


But, really, that doesn't buy you any real protection, either...  Because, the only thing
you're protecting against is sniffing of the plaintext password on the wire, and in this
scenario they no longer even need the plaintext password: instead, they can just
sniff the intermediate hash off the wire, and retransmit that instead, and it's exactly
the same as if they had sniffed the plaintext password since it functions identically...

No, it's not the same. In one case the plaintext password is known and in the
other it's not.

I don't know anyone who doesn't use the same password for multiple accounts,
so the password itself is sensitive info and worth protecting. So it might not
help protecting your system, but it does protect the user if you never send the
plaintext password to the server.

Also, if you make the local hashing computationally expensive then doing
dictionary attacks against the server is harder too. But the main purpose
was to protect the plain text password.

If you have control over the client, doing some kind of challenge/response
authentication is a lot better in case of fake servers that pretend to be the
original one. SSL won't protect you against that, or only partially (simple
man in the middle attacks). You don't want people falling for simple fishing
attacks.

Personally, if I wanted maximum security I'd use local hashing and a simple
key setup phase where the server gives the client a random key which is used
to generate the session encryption key according to the user's password hash.
Then use a stream or block cipher for the rest of the communication. That
way the server never gets the plaintext password, the client can verify the
server, and the whole thing is simple but very secure.

(Can still use libssl/openssl for the encryption, just no need to use the SSL part.)

Offline

#18 2010-08-16 10:37 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,769
Website

Re: Creating a database

I don't know anyone who doesn't use the same password for multiple accounts,
so the password itself is sensitive info and worth protecting.

Well, ok, sure, if you're going to allow for bad user behavior, and worry about
protecting those bad users who ignore the advice spouted by every single security
admin since the beginning of time: Never use the same password on multiple
different sites! ;-)  (Yes, yes, I do it too...  But, if my password got exposed on one
site, I know I'd only have myself to blame for the hassles of needing to change it
everywhere else too...  I certainly try not to do it anywhere it really matters much,
anyway...  But, most places that matter tend to be SSH logins, for which I only ever
login via auth keys anyway, so whatever weird thing I set my password to doesn't
much matter, even if I forget it...)

But, you know, if your idea caught on and EVERY site you used that compromised
password on used your scheme, then it WOULD be identical to losing the plaintext
password...  So, the only reason it's any more secure would be its obscurity...  And,
really it would be everyone else's sites that are more secure in this situation, since
yours is the only one that could be broken into via the sniffed hash (and, of course,
could also be broken into if the plaintext password were known, as well, just like
all the other sites)... ;-)

Also, if you make the local hashing computationally expensive then doing
dictionary attacks against the server is harder too.

True, and that's a good point in its favor...  But, you could also just do the standard
"slow down and/or disconnection on multiple failures" on the server side, and limit
simultaneous unauthed connections from the same IP...  (Yeah, the real bad guys
these days will just send a botnet after you from a million different IPs...  But, if they
already have that kind of power at their command, then they could also easily deal
with added local computational complexity with no problem...)

in case of fake servers that pretend to be the
original one. SSL won't protect you against that

Well, if you properly verify certs, it sure should...

Personally, if I wanted maximum security I'd use local hashing and a simple
key setup phase where the server gives the client a random key which is used
to generate the session encryption key according to the user's password hash.
Then use a stream or block cipher for the rest of the communication. That
way the server never gets the plaintext password, the client can verify the
server, and the whole thing is simple but very secure.

Interesting...  But, if the server's list of hashes were compromised, couldn't an
attacker still authenticate then, without even needing the password?

Offline

#19 2010-08-17 11:59 AM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,205

Re: Creating a database

RobSeace;30370 wrote:

Well, ok, sure, if you're going to allow for bad user behavior, and worry about
protecting those bad users who ignore the advice spouted by every single security
admin since the beginning of time: Never use the same password on multiple
different sites! ;-)


There's also the matter that passwords contain privacy sensitive information.
You don't want the world to know your pet's name if one site gets hacked. =)

But, you know, if your idea caught on and EVERY site you used that compromised
password on used your scheme, then it WOULD be identical to losing the plaintext
password...  So, the only reason it's any more secure would be its obscurity...  And,
really it would be everyone else's sites that are more secure in this situation, since
yours is the only one that could be broken into via the sniffed hash (and, of course,
could also be broken into if the plaintext password were known, as well, just like
all the other sites)... ;-)

No, because the fixed user salt would be different. If they hash username +
password + uniquetoken it's fine. It also won't be less secure, because if they
sniff the hash they would have sniffed the plaintext password otherwise.

If they all just hash in the same way the plaintext password is still protected,
so it's always more secure. I repeat: Protecting the password itself is valuable
too.

Sending the hash doesn't mean there's a new attack vector, because it's send
instead of the single plaintext password.

Well, if you properly verify certs, it sure should...


No, it won't, because the peer would be different. There's a reason phishing
attacks are so common. But if there's nothing to fish for, they're useless.
You can make it harder for them by having all kind of kludges, but it only
makes the whole more complicated.

If you want security then the last thing you want is complexity.

Interesting...  But, if the server's list of hashes were compromised, couldn't an
attacker still authenticate then, without even needing the password?


Of course, but this is unavoidable. If the attacker has all the info the server has
it can always log in, no matter what scheme is used. In this case the server is
pretty much compromised, because the step from reading random files to full
control isn't that big.

To make this less likely you can encrypt the stored hashes (a good idea anyway)
and give the master key at server startup and only store it in (pinned) memory.

Offline

#20 2010-08-17 01:25 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,769
Website

Re: Creating a database

No, because the fixed user salt would be different.

Ah, ok...  The way I read your original idea, the salt would be left entirely up to the
server-side rehashing of the unsalted hash from the client...  Since the client would
have no idea what salt to use without the server telling them, anyway...  If you're
also salting the client hash sent over the wire, then yeah that effectively prevents its
reuse on other sites...

No, it won't, because the peer would be different. There's a reason phishing
attacks are so common.

Are you just talking about people being stupid enough to go to a site with a completely
different domain name than the one they really wanted to go to, and be fooled into
thinking it's legit?  That seems more likely to be an issue with web sites than something
like this, which I assumed was intended to be a stand-alone server app of some
sort, handling user logins...  Ie: you don't hear about a lot of people SSH'ing into
phishing sites, do you?  Plus, I kind of figured it was just going to be a single
server somewhere at a fixed location, in which case the client could just be
hard-coded to use that location, eliminating any possibility of user error...  And, in
that case, I think verifying its SSL cert will indeed take care of spotting any trickery
attempted...

Even allowing for multiple servers and user-entered host names to connect to, you
could require each server be signed by a particular unique CA that only you control,
in which case no one else could forge a cert that you'd accept...  However, if this is
intended to be a widespread open sort of system a la the web, where anyone can
setup a server, then of course you have the problem of some of those "anyones"
being assholes out to screw people over...  Not much you can do about that...  But,
for private systems fully under your control, it should be pretty damn simple to stop
any such trickery...

Of course, but this is unavoidable. If the attacker has all the info the server has
it can always log in, no matter what scheme is used.

No, that's just wrong...  Take the standard Unix login system, for example...  If
someone manages to steal "/etc/shadow", they CAN'T automatically just login as
any user on that system now...  First, they need to try to crack those hashes into
actual passwords they can use...  Which, if you're using good passwords, they may
not be able to actually do at all...  That's sort of the whole damn point of storing the
hashes on the server side instead of the plaintext passwords in the first place!

Offline

#21 2010-08-17 03:18 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,205

Re: Creating a database

RobSeace;30375 wrote:

Are you just talking about people being stupid enough to go to a site with a completely
different domain name than the one they really wanted to go to, and be fooled into
thinking it's legit?


That's one way. Another is DoSing the original one and taking over the session
without pretending to be the original server as far as certificates goes.

It gets hairy, both on the attack and the defend side. But relying on human
stupidity always works. :-)

No, that's just wrong...  Take the standard Unix login system, for example...  If
someone manages to steal "/etc/shadow", they CAN'T automatically just login as
any user on that system now...  First, they need to try to crack those hashes into
actual passwords they can use...  Which, if you're using good passwords, they may
not be able to actually do at all...  That's sort of the whole damn point of storing the
hashes on the server side instead of the plaintext passwords in the first place!

Yes, I got confused. I was talking about a client login in to a fake server having
the compromised hashed. Then the fake server can let the client login without
the client knowing whether it's the real server. But I totally forgot the reason
for locally hashing too, so it seems an additional step is required in my
approach if you want this: After creating the session key, the client has to
send its hash so the server can verify if it double hashes to the stored hash.

Offline

#22 2010-08-17 03:22 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,205

Re: Creating a database

Oh, and one big downside of my approach: You still need a secure way of
exchanging the password hash.

Offline

#23 2010-08-17 07:48 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,769
Website

Re: Creating a database

Oh, and one big downside of my approach: You still need a secure way of
exchanging the password hash.

Yeah, so I'm not sure it's ultimately any better than simply sending the plaintext
password (over an encrypted channel)...  You need a secure channel in either case,
so the extra hashing seems mostly pointless...

Of course, I'd say just scrap the whole notion of passwords and use something like
SSH RSA/DSA auth keys, where both sides can happily send the public half of their
key in the clear and still be safe, because any attacker would need access to the
corresponding private key in order to actually login...  (And, for added security, they
can encrypt the private key files so they're useless to an attacker that manages to
steal them, as well...  Then, things will function roughly the standard way: the user
gets prompted for a password at login time...  It's just that the password/phrase is
used for decrypting the private key file instead of actually logging in remotely...)

Offline

#24 2010-08-17 07:56 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,205

Re: Creating a database

Sending the plain text password should never be done, just send the hash.
It's only one extra hash on the client side, nothing needs to change on the
server side.

But yeah, once you need SSL, you can as well do the RSA thing both ways.

Offline

#25 2010-08-18 01:40 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,769
Website

Re: Creating a database

Sending the plain text password should never be done, just send the hash.

Even over a secure channel?  Are you worried about the password being read out
the address space of the server process now, or something?  Or the secure
channel being compromised?  Or what??

Based on that logic, it seems like you should never send ANY sensitive info over a
secure channel...  And, I don't know about you, but *I* send tons of info FAR more
sensitive than my damn password (CC#, SS#, checking account#, etc.) over secure
channels pretty much every day...  If there were a problem with sending sensitive
info over secure channels, well I'd have a hell of a lot more to worry about than just
my damn passwords being exposed, that's for sure...

Offline

Board footer

Powered by FluxBB