Skip to content

security issue with users providing their institution's username and password to DTS #4

@GoogleCodeExporter

Description

@GoogleCodeExporter
Had a meeting with everyone in VPAC funded by ARCS and talked about the
project and some issues Sam and Markus brought up at the last chat I had
with them. The problem is, we can't give "users will learn to trust us just
like how they trust their banks" as an argument because we're a third
party. We know that with banks, our credentials, pin numbers only travel
within their network. Ok, how about using credit cards then? Oh, that's a
different case because there's a system where we can get our money back if
something bad happens. Even if can come up with a way to make it very
secure on the DTS server, it's still against a site's end user agreement to
give a user's password to a third party service. Having that document that
Carlos suggested, an audit document to be 'security certified' that states
we won't log a user's credentials anywhere on the system is not acceptable
to the guys because one, we're not a Bank and two, it's against an
employee's end-user-agreement to give their username and password to us
who's considered a third party.

Carlos (on 2/07) has just pointed me to a couple of non-bank interbank
networks (CIRRUS and PLUS) that are trusted by the banks. Building trust is
not an easy thing and just like what Carlos has said, building trust will
take years to grow. 

Original issue reported on code.google.com by gerson...@gmail.com on 6 Nov 2009 at 4:41

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions