Re: password datatype in RDF

I seem to have received advise about how to store passwords, but 
actually my question was about how to represent passwords in RDF.

In my use case the password is typed in by a user, and later (perhaps 
week's later) presented by the system to another application.

This means that my system needs to be able to access the text (not just 
the encrypted text) that the user typed in.

I see this as essentially one triple:

eg:account eg:password "secret text that needs to be protected when 
stored or on the wire or in a display" .

I see it as function of my system to be able to appropriately protect 
the secret text, and appropriately decrypt it when it is actually needed.
I doubt it is economic to do that brilliantly, but several systems seem 
to go with the approach of:
a) obfuscating the text so the casual user cannot read it
b) ensuring entry of the text uses ****s
c) accessing the unobfuscated text is by some API that is under the 
system control
For example, the way eclipse stores SVN passwords, or (I think) 
Thunderbird stores mail account passwords.

These issues seem completely separate from my question, which was, in my 
system, 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 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 17:35:55 UTC