jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2919) Security of token base authentication
Date Fri, 18 Mar 2011 10:29:29 GMT

    [ https://issues.apache.org/jira/browse/JCR-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008391#comment-13008391
] 

Thomas Mueller commented on JCR-2919:
-------------------------------------

revision 1076597 uses:
if (System.getProperty(NodeIdFactory.SEQUENTIAL_NODE_ID) == null) {
  ...
}

I think security shouldn't check this setting, and shouldn't rely on (the 'security of') node
ids in general. Not sure if that's related, but it's possible to import nodes with fixed node
ids. The fact that node ids are randomly generated is just an implementation detail of the
current Jackrabbit.

Wouldn't it be simpler to store the token as a property _value_? Or instead of storing the
token itself, store the (secure) hash code of the token as a value?


> Security of token base authentication
> -------------------------------------
>
>                 Key: JCR-2919
>                 URL: https://issues.apache.org/jira/browse/JCR-2919
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core, security
>    Affects Versions: 2.3.0
>            Reporter: Michael Dürig
>
> Token based authentication as implemented with JCR-2851 seems to exhibit a security issue:
the token returned by the server consists of the identifier of a (newly created) node in the
repository. An attacker who is able to guess (or acquire by other means i.e. via log files)
that identifier will be granted access to the repository. Worse yet, JCR-2857 introduces sequential
node ids. Guessing is a piece of cake in such a setup.
> I think we should decouple authentication secrets from node ids. A simple solution would
be to store the secret in a token attribute and delegate generation of the secret to a dedicated
handler. Such a handler can then use a secure random generator, private/public key encryption
or whatever other method that is deemed appropriate to generate the authentication secret.

> Initial discussion see: http://markmail.org/thread/aspetgvmj2qud25a

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message