But what about them hackers?

M

Martin

Hi all,

We have an administrative application that we are considering to rewrite in
aspx with vb2005. I think the marketing possibilities are enourmous.

In our standard app, the user logs in by entering his/her user name and
password. In the online version that would be Client ID / user ID /
Password. So far so good. But I'm just wondering... how secure is this? I
guess not very. Every disgruntled employee can go online at home enter their
name and password and do whatever they like.

Now for clients with a fixed IP address I can check the IP-address as a part
of the authentication. But what if my client has a dynamic IP-address?

I would love to hear your thoughts on this matter,

Thanks,
Martin
 
G

Guest

Username and password in combination with forms authentication or windows
authentication should be secure enough

if you use forms Authentication and use a DB as storage use parameterized
query`s or SP`s to protecet against SQL injection

About the employe that abuses his account ,,, it should be clear that anyone
who has the keys to your house can steall everything what is inside , however
if you arrive at your home and everything is gone without anny traces of
burglary
it would sure limit the amount of suspects .

regards

michel
 
J

Jeff North

| Hi all,
|
| We have an administrative application that we are considering to rewrite in
| aspx with vb2005. I think the marketing possibilities are enourmous.
|
| In our standard app, the user logs in by entering his/her user name and
| password. In the online version that would be Client ID / user ID /
| Password. So far so good. But I'm just wondering... how secure is this? I
| guess not very. Every disgruntled employee can go online at home enter their
| name and password and do whatever they like.
|
| Now for clients with a fixed IP address I can check the IP-address as a part
| of the authentication. But what if my client has a dynamic IP-address?
|
| I would love to hear your thoughts on this matter,

You might want to re-think this process.
I would be thinking - who do I want to allow on the system and what
rights would I give them. What information do I know for certain and
can control?

The only IP addresses that you know, and can control, are the
workplace ones. Thus, people who login from the workplace are given
full access.

Anyone logging in from outside (any other IP address) would only be
given readonly/minimal update priveleges.

You can have a look at Authentication and Roles as used in the
web.config file.

(I'm very much new to ASP.NET myself)
 
M

Martin

Hi Michel,

Thanks for your reply. You got a good point there. Besides we will log all
usage including IP address for audit and billing purposes, so if it is an
"inside job" we'd know the culprit.

The thing that worries me somewhat is outsiders (hackers). I know you can
scramble the password in the database, but still.... You hear of people
breaking in into the CIA system, and I bet those guys know a lot more about
security than I do.

The system will store sensitive medical and personal info of patients as
well as financial data of hospitals.

I hear SP's are a good way of protecting a database, but frankly I don't
understand how. A stored procedure can be called by anyone with access to
the database right? And the database will still be open to regular queries,
or am I seeing that wrong?
 
M

Martin

Hi Jeff,

Thanks for your response. Of course we don't give anyone with a password
access to the entire system. There are quite elaborate profiles that
determine per window if a user has rights, and if so, which those rights
are. This is the case in the current Windows version, and we certainly would
do no less in an online version.

The thing I'm worried about is how easy would it be for an experienced
hacker to hijack a password/username combination and either steal
information or do damage to the data.

Many of our clients would have fixed IP-addresses, so they could supply a
list of IP-addresses who'd have access, and we simply deny anyone who tries
to log-on on behalf of this specific client from any other IP address. But
some of our clients would have changing IP-addresses. In that case we cannot
do this. We'd just have to believe the person who says I'm working for this
hospital, this is my name and this is my password.

Thanks,
Martin
 
H

Herfried K. Wagner [MVP]

Martin said:
We have an administrative application that we are considering to rewrite
in aspx with vb2005. I think the marketing possibilities are enourmous.

In our standard app, the user logs in by entering his/her user name and
password. In the online version that would be Client ID / user ID /
Password. So far so good. But I'm just wondering... how secure is this? I
guess not very. Every disgruntled employee can go online at home enter
their name and password and do whatever they like.

HTTPS + username + password should be secure enough in most cases. However,
do not store the passwords in plain text on the server. Instead, store a
salted hash in the users table.
 
M

Martin

Hi Herfried,

Thank you for your response. I've read in the VB documentation about storing
the passwords hashed. But salted? I haven't heard of that flavour.

Do you have any suggestions where I can read more about https?

Thanks,
Martin
 
T

tomb

Martin said:
Hi all,

We have an administrative application that we are considering to rewrite in
aspx with vb2005. I think the marketing possibilities are enourmous.

In our standard app, the user logs in by entering his/her user name and
password. In the online version that would be Client ID / user ID /
Password. So far so good. But I'm just wondering... how secure is this? I
guess not very. Every disgruntled employee can go online at home enter their
name and password and do whatever they like.

Now for clients with a fixed IP address I can check the IP-address as a part
of the authentication. But what if my client has a dynamic IP-address?

I would love to hear your thoughts on this matter,

Thanks,
Martin
I use a combination of username/password/machineid stored in the
database. If a user tries to login from a different machine, the
machineid won't match, therefore no login. The machineid I use is a
combination of hard drive info and machine name.

Tom
 
G

Guest

Hi,

In addition to the other responses. I would authenicate the user
againist the activedirectory. This way system administrator can set access
levels and disable or delete users.

Ken
 
J

james

Martin said:
Hi Michel,

Thanks for your reply. You got a good point there. Besides we will log all
usage including IP address for audit and billing purposes, so if it is an
"inside job" we'd know the culprit.

The thing that worries me somewhat is outsiders (hackers). I know you can
scramble the password in the database, but still.... You hear of people
breaking in into the CIA system, and I bet those guys know a lot more
about security than I do.

The system will store sensitive medical and personal info of patients as
well as financial data of hospitals.

I hear SP's are a good way of protecting a database, but frankly I don't
understand how. A stored procedure can be called by anyone with access to
the database right? And the database will still be open to regular
queries, or am I seeing that wrong?

Not that I am an expert... but the queries would only be runnable by your
code (the pages run under a certain account), the SQL Server (or whatever DB
Backend you use) would never be exposed to the external world... so as long
as you prevent against SQL Injection you should be safe (from that aspect!)
James.
 
J

james

Martin said:
Hi Herfried,

Thank you for your response. I've read in the VB documentation about
storing the passwords hashed. But salted? I haven't heard of that flavour.

Do you have any suggestions where I can read more about https?

Salt is the encryption "key" used to encrypt the hash. So if you make this
complex too, it is more secure.

A different "salt" will give a different encrypted string....
 
M

Mythran

Martin said:
Hi all,

We have an administrative application that we are considering to rewrite
in aspx with vb2005. I think the marketing possibilities are enourmous.

In our standard app, the user logs in by entering his/her user name and
password. In the online version that would be Client ID / user ID /
Password. So far so good. But I'm just wondering... how secure is this? I
guess not very. Every disgruntled employee can go online at home enter
their name and password and do whatever they like.

Now for clients with a fixed IP address I can check the IP-address as a
part of the authentication. But what if my client has a dynamic
IP-address?

I would love to hear your thoughts on this matter,

Thanks,
Martin

Ahh security, don't ya just love it! :p

To prevent outside manipulation of the database and/or any other services on
your server(s), try placing both the dbms machine and web server (or the
server that hosts both if thats the case) behind a secured firewall. You
can open up the firewall to allow communication from the outside world to
your web server for web serving only. This would prevent direct
manipulation of the database. Although in theory this works, it still
depends on how good you write the application. If you don't use stored
procedures, and you don't code defensively, you then may allow hackers to
breach your database by use of sql injection attacks.

Also, make sure all machines (servers) are fully patched with the latest
security patches from Microsoft, this is important. If you don't, then a
security hole that is discovered and fixed won't be fixed on your machine,
therefore possibly allowing alternate methods of attack on your server for
hackers. Although, the firewall *should* prevent such attacks anyways, you
never know when dealing with security :)

HTH,
Mythran
 
G

Guest

the idea of salt IV is that the encryption algorythm becomes a roling code

so encrypting 2 times bla wil give two different encrypted values

however to make it even more secure you could use a one way hash
the values are then stored in encrypted form and there is no way to get it
decrypted

you authenticate with the encrypted values against the encrypted stored
values in the db , this way even you do not know the password

how secure can you get :)

see this nice article on devx for some more info
http://www.devx.com/dbzone/Article/26726/0




regards

Michel Posseth
 
A

_AnonCoward

: Hi Michel,
:
: Thanks for your reply. You got a good point there. Besides we will log all
: usage including IP address for audit and billing purposes, so if it is an
: "inside job" we'd know the culprit.
:
: The thing that worries me somewhat is outsiders (hackers). I know you can
: scramble the password in the database, but still.... You hear of people
: breaking in into the CIA system, and I bet those guys know a lot more
: about security than I do.
:
: The system will store sensitive medical and personal info of patients as
: well as financial data of hospitals.
:
: I hear SP's are a good way of protecting a database, but frankly I don't
: understand how. A stored procedure can be called by anyone with access to
: the database right? And the database will still be open to regular
: queries, or am I seeing that wrong?

Do a search on "SQL Insertion". Consider the following SQL select statement
(where id and pwd are form variables passed in from a web request):

"Select * From MyTable " & _
"Where id='" & id & "' And pwd = ' & pwd & "'"

Let's say your user entered the following values in a form submission:

id = "Ralf"
pwd = "1234567"

This would render sql as follows:

"Select * From MyTable " & _
"Where id='Ralf' And pwd = '1234567'"

All well and good. However, suppose he enters the following values instead:

id = "Ralf' Or 1=1 --"
pwd= ""

This would render sql as follows:

"Select * From MyTable " & _
"Where id='Ralf' Or 1=1 --'And pwd = ''"

The "--" are comments in SQL so everything following it would be ignored.
This leaves:

"Select * From MyTable " & _
"Where id='Ralf' Or 1=1"

Since 1=1 will resolve to true, the statement would return all records from
MyTable even though the user didn't have a valid id/pwd values.

Stored procedures don't have that vulnerablilty. In that case, the SP would
look for a user id value of "Ralf' Or 1=1 --" which presumably would not be
found.

<snip>

Ralf
 
M

Martin

Thanks everybody for your helpful contributuons to this discussion.

I have a few (maybe stupid) questions... What is that SQL Injection thingy I
keep hearing about, and does anyone know a site where i could learn about
HTTPS?

Tia,
Martin
 
C

Cor Ligthert [MVP]

Peter,

The page you show is in my idea one of the worst pages on MSDN. It is a kind
of hacker manual, while the given samples don't secure any hack.

If you want to secure hacking with SQL server than you need to do that in
your SQL server part where by instance not any part of the data is direct
readable by somebody else than the Admin, and the Stored procedures will
have the authorisations who may use those procedure by procedure. But the
first part for hacking (as it is as well in this article) is that you need
the userID and the passwords who gives you the right to connect to the SQL
server or whatever. I probably don't have to give you than the code how to
access a bad managed SQL server a SP alone does than nothing to prevent
that.

AFAIK had the SQL injection something to do with a bug in SQL 2000 server,
where I have never read what it was. SP3 from SQL 2000 server should be to
correct that bug.

Just a little addition,

Cor
 
M

Mythran

Peter Proost said:
Cor,

ACK, but it does explain what SQL injections are ;-)

Greetz Peter

Which is also where I learned about it too...hmm, MSDN does provide an
arsenal for hackers...but then again, so does any development
book/manual/site. It would have been much better if it provided a detailed
approach on how to avoid being hacked in such a way...in any case, Cor is
right...

Mythran
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top