Re: password datatype in RDF

>  I wish to signal to the infrastructure that the string "secret text
> that needs to be protected when stored or on the wire or in a display"
> needs to be protected ....
>
> My colleague suggested a datatype, we would then add a range on 
> eg:password to indicate that it was always this datatype (useful on data 
> entry).

I don't think the notion of datatype is right to use this way.  A
datatype is (roughly) a mapping from a lexical space to a value space,
and in the case you're talking about, the mapping for passwords would be
the same as xs:string, so I think it should be the same datatype.

(As an aside: the 2004 XML Schema Datatypes spec actually leaves the
notion of a mapping out of the definition of a datatype:

    In this specification, a datatype is a 3-tuple, consisting of a) a
    set of distinct values, called its ·value space·, b) a set of
    lexical representations, called its ·lexical space·, and c) a set of
    ·facet·s that characterize properties of the ·value space·,
    individual values or lexical items.

         -- http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

Fortunately, xsd 1.1 [1] avoids this "3-tuple" nonsense, but it's not
clear to me if the new formulation bears on your question.)

I think the lightest-weight approach here is to annotate the password
property.    Rather than:

    eg:password rdfs:range eg:password

say

    eg:password eg:displayType eg:blanked

or something like that.   

Alternatively, I expect a real RDF Forms system needs to control other
features, like the order in which the properties are displayed on the
screen, maybe with grouping, layout, rollover-documentation, etc.
However that is handled, it could probably be extended to passwords, and
that seems like the right place for it.  (I don't think anyone but the
UI needs to know this property is in any way special.  If your channel is
not secure, then let the UI handle the crypto so the channel doesn't
need to be secure.)

     -- Sandro


[1] http://www.w3.org/TR/2009/WD-xmlschema11-2-20091203/#datatype 







> I still don't believe this is a novel problem, the solutions so far seem 
> to have been very system specific, and concentrated on the uninteresting 
> mechanics of security, rather than the RDF question of appropriate 
> interoperable representation.
> 
> Perhaps there are two distinct cases:
> - a store and forward password, for which usual system functions (e.g. 
> SPARQL queries) need a certain amount of confusion, but there is some 
> mechanism for getting the original text out
> - a store and verify password, where the original text is lost, and 
> cannot be restored, but can be verified (for checking password on entry).
> 
> The latter seems less interesting than the former, since the former is a 
> basic building block in integrating different information systems, which 
> seems to be the fundamental motivator for SemWeb.
> The latter is needed (on many computer systems, has many adequate 
> solutions, and using SemWeb technology for it seems a bit obsessive.
> 
> Jeremy
> 
> 
> 
> 
> Steve Harris wrote:
> > On 3 Feb 2010, at 23:26, Jeremy Carroll wrote:
> >>
> >> We have an RDF based form, where some of the details of the 
> >> presentation are decided late, based on the data and its schema.
> >>
> >> For our application, we need to enter various SMTP setup information 
> >> in this form, including a username and password.
> >> Right now, the password appears in clear-text ... :(
> >>
> >> A colleague suggested that we invent a new datatype:
> >>
> >> tq:password rdfs:subClassOf xsd:string .
> >>
> >> and then upgrade our form presentation software to treat this 
> >> datatype with the conventional ****s
> >>
> >> That seems like a reasonable approach, has it been done before? Is 
> >> there a datatype to reuse, or some other method?
> >
> > Jeremy,
> >
> > I like Yihong's approach, but if that's not palatable for some reason 
> > you could crypt the password string with a strong shared-secret key, 
> > rather that storing it as plain text*. Without knowing the exact 
> > system involved it's hard to know what the risk profile is like (it 
> > could be some trivial resource that's being protected), but it's 
> > inadvisable to ever store passwords in plain text - users have a habit 
> > of reusing the same password for multiple resources.
> >
> > * I am not a cryptographer. This might not be the right thing, my 
> > understanding is that ideally you would just store the salted hash of 
> > the password.
> >
> > For what it's worth, we never store unhashed passwords.
> >
> > - Steve
> >
> 
>

Received on Thursday, 4 February 2010 21:18:35 UTC