[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
Re: [mv] Userdb password security/ Security ?
****** message to minivend-users from "Gideon van Gelder" <gideon@swingmaster.nl> ******
Hi List,
Of course all of this, when you're using PGP 5.0/ 3072-bit Diffie-H.
encryption doesn't pose an immediate threat: the worst thing that could
happen is that a Minivendor with a vengeance comes in and tries to loop
through your userdb, which with me would fail because of two things:
one of them is because, as I told, changed my userdb name to a word that
only I could guess, mind you: database names are case-sensitive which
make guessing for an "intruder" impossible, to my opinion.
Furthermore, when your site gets so busy it gets interesting to hack,
the MV-server isn't what should be your primary concern if you use
encryption;
it's much more "likely" that someone tries to get in to your actual server,
than that that someone is able to see you're using MV (1.)
Knows MV well enough to be able to loop through your db(2.)
Probably won't succeed in doing (2.) when you've changed the DB-name. (3.)
(4.) Even when he finds your user info, it's pretty worthless since not
everyone
has a number-crunched with 20 parallel processors in his cellar for
crunching
3072-bit Diffie Helman-keys.
This is all from an amateurs point of view with an extremely gotten-out of
hand hobby!
Where are the experts?
-Gideon
> ****** 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
-
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
