Re: [mv] Userdb password security/ Security ?

["B.J. Bezemer" <bas.bezemer@wxs.nl>]

******    message to minivend-users from "B.J. Bezemer" <bas.bezemer@wxs.nl>     ******

Hi All,

It has been very quiet after Gideons question on this topic and I can't
imagine that Joachim and I are the only one that shivered for a moment.
Ofcourse there are tricks or workarounds to fix this problem. You could
rename the database from userdb to the name of a loved one in reverse order,
with some numbers in it, but that is not a structural solution. The password
field is not the only information that I don't want to be made public. I
don't want anyone to snoop into my database where I keep all my information
on orders (addresses of my customers, how much they ordered etc.).

With minivend you can fire the complete range of minivend commands and
parameters at any given shop in addition to the ones that the shop owner
expects. In addition to Gideons suggestion, you can do for example:
1) With [page form=""] you can request any database query by definition of
mv_sql_query
2) If a shop uses mv_data_table and mv_data_function ("update" and "insert")
somewhere, people with bad intentions can use it to add field to
mv_data_fields to achieve certain benefits. You yourselves invited people to
write directly into your database by giving [tag flag write]. (BTW: how can
you erase a certain field, using this definition?)

I think it should be possible in minivend to have more control on the
requests visitors make. How can that be achieved in minivend? Well:
[loop arg="1 2 3"]
1) Minivend should no longer directly accept any (minivend-)parameters given
on a submition. Every parameter the visitor sends is automatically
translated to a "value" in the user session or is accepted as a search or
order parameter. Why is that? Why should the over active visitor be able to
spoil the user session with variables I didn't expect him to send?.
2) Every request must have some sort of profile definition (search profile,
order profile, mv_check or mv_click). If a request does not contain a
profile an error message should be given to the visitor. 3) In the profile
you define which parameters you DO expect and accept. If you expect the
variable "name" you can accept it to the "values"-namespace with something
like:
name=[cgi name]

or to accept a list of user set variables:
&accept name, address, zip

or to define a search string set in the variable "query":
mv_searchspec=[cgi query]

A personal favourite would be to be able to accept a variable only if it is
within a certain range or list. If I present the customer on the checkout
page a list of countries I am willing to ship to (only Europe for instance),
I don't want want any request for Azia, Afrika or America in general, to
appear in my order database:
&list country [BE DE FR SP NO SW LUX DK FI PT GR IT NL]

Everything else is not accepted and interpreted (like for instance
mv_search_file=userdb) if you don't want it to be.
[/loop]

Another thing: If you are able to guard your user session at the gate, why
should there be a seperate "scratch" and "values" namespace.

Just my thoughts. And I had the afternoon off.

Greetings,
Bas Bezemer







> ******    message to minivend-users from jojo@buchonline.net     ******
>
> On 22 Jan, To: mvendweb wrote:
> >
> >
> > -------- Original Message --------
> > Subject: [mv] Userdb password security/ Security ?
> > Date: Sat, 22 Jan 2000 00:00:58 +0100
> > From: "Gideon van Gelder" <gideon@swingmaster.nl>
> > Reply-To: minivend-users@minivend.com
> > To: <minivend-users@minivend.com>
> > References: <002101bf644f$cf8d4840$0c01a8c0@steven>
> > <0001211708210P.23987@arcane.specialty-books.com>
> >
> > ******    message to minivend-users from "Gideon van Gelder"
> > <gideon@swingmaster.nl>     ******
> >
> > Hi all,
> >
> > Now I am by no means a security expert.
> > What I did think of the other day, is that anyone can
> > very easily loop through all the userdb-passwords with this url:
> >
> > mystore.com/cgi-bin/mycat/rf=1/ra=yes/fi=userdb
> >
> > Since almost anyone uses the [item-code] reference somewhere
> > on their results-page, the password is bound to show up somewhere.
> > For your information, I already was successfull at about all
> > of the few MV-stores I tried this trick with.
> >
> > Now what I think is you can do two things:
> >
> > 1. change the name of your userdb to something else that can't be
> > guessed
> > at.
> >
> > 2. Use encryption; however I was told that perl-encryption is about
> > the worst encryption there is, so that could still mean a lot of
> > fun for a hacker, right ?
> >
> > What are your opinions ? Is this needless worrying (i don't think so).
> > Is there anyway to make the userdb not accessible from the url, or just
> > make it safer ?
> >
> > -Gideon
> >
> > P.s.  What is the current status on the export-restriction problem for
> > 128-bit browsers from the US ?(stupid NSA suckers...)
>
> Hi Gideon,
>
> i have test it and i can get the informations from userdb. I believe, i
> can patch some minivend module to prevent this (if i have time). But i
> would prefer, Mike Heins will add a feature like
>
> Database    userdb   userdb.asc     TAB secure
>                                         ^^^^^^^
>
> or other solutions to tell MV, to make the userdb file secure.
> I will not patch any minvend file.
>
> Regards,
>
> Joachim
>
> BTW: I use encryption and watch my webserverlogs!
>
> --
> Hans-Joachim Leidinger
> buch online                 jojo@buchonline.net
> Munscheidstr. 14            FAX: +49 209 1971449
> 45886 Gelsenkirchen         FAX: 0209 1671449
>
> -
> To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
> email with 'UNSUBSCRIBE minivend-users' in the body to
Majordomo@minivend.com.
> Archive of past messages: http://www.minivend.com/minivend/minivend-list
>

-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list