Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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
>> >
>>
>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB