Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS, mail # dev - block access token


Copy link to this message
-
Re: block access token
lei liu 2013-11-20, 04:11
Hi  Luke,

Can I set "dfs.block.access.token.lifetime" to two minutes?
2013/11/18 lei liu <[EMAIL PROTECTED]>

> Thanks Luke for your reply.
>
> The life time of block access token is ten hours,  whether we should
> change two minutes? I think the shorter the life time of the token, token less
> likely to be stolen.
>
>
> 2013/11/14 Luke Lu <[EMAIL PROTECTED]>
>
>> Block access token is only valid for a short period of time, as the NN/DN
>> shared secrets are rolled periodically. As long as you cannot steal block
>> token easily (besides using zero-day bugs), there is really no security
>> hole here (by design). If you know of a way to steal block tokens without
>> root access, let us know.
>>
>>
>> On Tue, Nov 12, 2013 at 7:30 PM, lei liu <[EMAIL PROTECTED]> wrote:
>>
>> > When client read block from DataNode, the block access token is used for
>> > authorization on DataNode. But if the block access token is stolen by
>> > impostor, the  impostor can read the block,
>> > I think this is one security hole.
>> >
>> > I think we can use the replay cache mechanism in Kerberos to resolve the
>> > question, example below explaining:
>> >
>> > The possibility exists for an impostor to simultaneously steal both the
>> > ticket and the authenticator and use them during the 2 minutes the
>> > authenticator is valid. This is very difficult but not impossible. To
>> solve
>> > this problem with Kerberos 5, Replay Cache has been introduced. In
>> > application servers (but also in TGS), there exists the capacity to
>> > remember authenticators which have arrived within the last 2 minutes,
>> and
>> > to reject them if they are replicas. With this the problem is resolved
>> as
>> > long as the impostor is not smart enough to copy the ticket and
>> > authenticator and make them arrive at the application server before the
>> > legitimate request arrives. This really would be a hoax, since the
>> > authentic user would be rejected while the impostor would have access to
>> > the service.
>> >
>> >
>> > Thanks,
>> >
>> > LiuLei
>> >
>>
>
>