Saturday, 20 September 2014

Time-based One-time Password Algorithm

Time-based One-time Password Algorithm (TOTP) is an algorithm that computes a one-time password from a shared secret key and the current time. It has been adopted asInternet Engineering Task Force standard RFC 6238,[1] is the cornerstone of Initiative For Open Authentication (OATH) and is used in a number of two factor authenticationsystems.
TOTP is an example of a hash-based message authentication code (HMAC). It combines a secret key with the current timestamp using a cryptographic hash function to generate a one-time password. The timestamp typically increases in 30-second intervals, so passwords generated close together in time from the same secret key will be equal.
In a typical two-factor authentication application, user authentication proceeds as follows: a user will enter username and password into a website or other server, generate a one-time password for the server using TOTP running locally on a smartphone or other device, and type that password into the server as well. The server will then also run TOTP to verify the entered one-time password. For this to work, the clocks of the user's device and the server need to be roughly synchronized (the server will typically accept one-time passwords generated from timestamps that differ by ±1 from the client's timestamp). A single secret key, to be used for all subsequent authentication sessions, must have been shared between the server and the user's device over a secure channel ahead of time. If some more steps are carried out, the user can also authenticate the server using TOTP.


TOTP is based on HOTP with a timestamp replacing the incrementing counter.
The current timestamp is turned into an integer time-counter (TC) by defining the start of an epoch (T0) and counting in units of a time step (TS). For example:
TC = (unixtime(now) - unixtime(T0)) / TS
TOTP = HOTP(SecretKey, TC), where the HOTP algorithm is defined below.
TOTP-Value = TOTP mod 10d, where d is the desired number of digits of the one-time password.
  • K be a secret key
  • C be a counter
  • HMAC(K,C) = SHA1(K ⊕ 0x5c5c... ∥ SHA1(K ⊕ 0x3636... ∥ C)) be an HMAC calculated with the SHA-1 cryptographic hash algorithm
  • Truncate be a function that selects 4 bytes from the result of the HMAC in a defined manner
Then we define
HOTP(K,C) = Truncate(HMAC(K,C)) & 0x7FFFFFFF
The mask is used to disregard the most significant bit to provide better interoperability between processors.[citation needed]


According to RFC 6238, the reference implementation is as follows:
  • Generate a key, K, which is an arbitrary bytestring, and share it securely with the client.
  • Agree upon an epoch, T0, and an interval, TI, which will be used to calculate the value of the counter C (defaults are the Unix epoch as T0 and 30 seconds as TI)
  • Agree upon a cryptographic hash method (default is SHA-1)
  • Agree upon a token length, N (default is 6)
Although RFC 6238 allows different parameters to be used, the Google implementation of the authenticator app does not support T0, TI values, hash methods and token lengths different from the default. It also expects the K secret key to be entered (or supplied in a QR code) in base-32 encoding according to RFC 3548.[2]
Once the parameters are agreed upon, token generation is as follows:
  1. Calculate C as the number of times TI has elapsed after T0.
  2. Compute the HMAC hash H with C as the message and K as the key (the HMAC algorithm is defined in the previous section, but also most cryptographical libraries support it). K should be passed as it is, C should be passed as a raw 64-bit unsigned integer.
  3. Take the least 4 significant bits of H and use it as an offset, O.
  4. Take 4 bytes from H starting at O bytes MSB, discard the most significant bit and store the rest as an (unsigned) 32-bit integer, I.
  5. The token is the lowest N digits of I in base 10. If the result has fewer digits than N, pad it with zeroes from the left.
Both the server and the client compute the token, then the server checks if the token supplied by the client matches the locally generated token. Some servers allow codes that should have been generated before or after the current time in order to account for slight clock skews, network latencies and user delays.


A TOTP draft was developed through the collaboration of several OATH members in order to create an industry-backed standard. It complements the event-based one-time standard HOTP and offers end user organizations and enterprises more choice in selecting technologies that best fit their application requirements and security guidelines. In 2008, OATH submitted a draft version of the specification to the IETF. This version incorporates all the feedback and commentary that the authors received from the technical community based on the prior versions submitted to the IETF.[3] In May, 2011, TOTP officially became RFC 6238.[1]

Server implementations[edit]

Client implementations[edit]

Wednesday, 17 September 2014

Open command window quickly from expolrer

Solution 1:
Under windows 7 or 8, hold Shift while Right-Clicking a blank space in the desired folder to bring up a more verbose context menu. One of the options is Open Command Window Here.

Solution 2:
In Windows 7 or 8, just type "cmd" to location bar, that's it. It will start a new command prompt in current path.
Keystrokes to move the focus to the location bar:
  • AltD in English 

Tuesday, 16 September 2014

Camel transacted route with onException

    // using required
    // all these steps will be okay
    .setBody(constant("Tiger in Action")).beanRef("bookService")
    .setBody(constant("Elephant in Action")).beanRef("bookService")
    // continue on route 2
    // tell Camel that if this route fails then only rollback this last route
    // by using (rollback only *last*)
    // using a different propagation which is requires new
    // this step will be okay
    .setBody(constant("Lion in Action")).beanRef("bookService")
    // this step will fail with donkey
    .setBody(constant("Donkey in Action")).beanRef("bookService");
Notice how we have configured the onException in the 2nd route to indicate in case of any exceptions we should handle it and just rollback this transaction. This is done using the markRollbackOnlyLast which tells Camel to only do it for the current transaction and not globally.

The onException should be specified before transacted() if it's a route specific one or as a global one.

Error handling in Camel

Error handling in Camel

Error handling in Camel can roughly be separated into two distinct types:
  • non transactional
  • transactional
Where non transactional is the most common type that is enabled out-of-the-box and handled by Camel itself. The transaction type is handled by a backing system such as a J2EE application server.

When does an error happen

An error happens when
  • any uncaught exception is thrown during routing and processing of messages within Camel
    So think of this as a big exception interceptor that catches all exceptions and handles what to do.

Non transactional

By default Camel uses the non transaction type and orchestrates the error handling during processing and routing.
As there isn't a single error handling configuration that suites all uses cases, you should consider altering the default configurations to better suit you needs.

Camel 1.x default error handler

In Camel 1.x a global Dead Letter Channel is setup as the Error Handler by default. It's configured as:
  • redeliver up to 6 times
  • pause 1 second between each redelivery attempt
  • if all redelivery attempts failed then move exchange into the dead letter queue
  • the default dead letter queue is a logger that logs the exchange at ERROR level (star)
Dead Letter Queue (*)
A dead letter queue is like a black hole, it will consume the Exchange and the Exchange routing is ended with no indication that it failed.
This works great in the JMS Messaging world where we don't want a bad message to cause endless retries and causing the system to exhaust. The message is said to be poison and thus we want to move it to a dead letter queue so the system can continue to operate and work with the next message.
This default does not go well with other transports using in a request/reply messaging style. If the Exchange failed then the original caller want to be alter it failed.
So the bottom line is that you must configure and setup the error handling strategies that suits your business needs.

Camel 2.0 onwards default error handler

In Camel 2.0 onwards a global DefaultErrorHandler is set up as the Error Handler by default. It's configured as:
  • no redeliveries
  • no dead letter queue
  • if the exchange failed an exception is thrown and propagated back to the original caller wrapped in aRuntimeCamelException.


Camel supports 2 scopes that is determined by the DSL in use:
Scope 1
Scope 2
Scope 2 takes precedence over scope 1
Java/Scala DSL
Scope 2 takes precedence over scope 1
When using XML DSL then scope 1 applies for all routes. Where as when using Java DSL then route 1 only applies for the given RouteBuilder instance. So if you have multiple RouteBuilder's then each route builder has its own scope 1.
If you want to share scope among RouteBuilder's you can use class inheritance and create a base class, and then extend this class for your RouteBuilder's and invoke the super.configure() method.
Mind that there was a bug in Camel that affected the scopes when using multiple RouteBuilder classes. See more details at CAMEL-5456.

How does the Dead Letter Channel error handler work

When Camel is started it will inspect the routes and weave in the error handling into the routing. With up to 3 supported scopes, the error handling can be quite complex. And on top of that you have inherited error handling and you can even configure Exception Clauses to handle specific exception types differently. So yes it's advanced but very powerful when you get the grip of it.
To keep things simple we first look at the basic concept how Camel orchestrates the redelivery attempt. At any given node in the route graph Camel intercepts the current Exchange being routed and wraps it with the Error Handler. This ensures that the Error Handler can kick in, just as the AOP around concept. If the exchange can be routed without any problems then it's forwarded to the next node in the route graph, But if there was an exception thrown, then the Error Handler kicks in and decides what to do.
An example illustrating this:
In this route we have 3 nodes (the dots) where the Error Handler is watching us (The AOP around stuff). So when an order arrives on the seda queue we consume it and send it to the validateOrder bean. In case the validation bean processed ok, we move on to the next node. In case the storeOrder bean failed and throws an exception it's caught by the Dead Letter Channel that decides what to do next. Either it does a:
  • redeliver
  • or move it to dead letter queue
It will continue to do redeliveries based on the policy configured. By default Dead Letter Channel will attempt at most 6 redeliveries with 1 second delay. So if the storeOrder bean did succeed at the 3rd attempt the routing will continue to the next node the confirmOrder bean. In case all redeliveries failed the Exchange is regarded as failed and is moved to the dead letter queue and the processing of this exchange stops. By default the dead letter queue is just a ERROR logger.
This applies to all kind of Components in Camel. The sample above only uses Bean but it's the same for FileMailVelocity or whatever component you use.


Camel leverages Spring transactions. Usually you can only use this with a limited number of transport types such as JMS or JDBC based, that yet again requires a transaction manager such as a Spring transaction, a J2EE server or a Message Broker.

How does it work

Camel 1.x
Camel does the same weaving as for the non-transactional type. The difference is that for transactional exchanges the Error Handler does not kick in. You can say the AOP around does not apply. Camel relies solely on the backing system to orchestrate the error handling. And as such the when the backing system does redeliver it will start all over again. For instance if the exchange was started by a JMS consumer then it's started again as the JMS message is rolled back on the JMS queue and Camel will re consume the JMS message again.
Camel 2.0
In Camel 2.0 we have empowered the TransactionErrorHandler to build on top of the same base thatDefaultErrorHandler does. This allows you to use Camel redelivery with transactional routes as well. The Spring transaction manager is still in charge and have the last say. But you can use Camel to do some local redelivery, for instance to upload a file to a FTP server, in which Camel can do local redelivery. So this gives you the power from both worlds. In case Camel cannot redeliver the exchange will be failed and rolled back. By default the TransactionErrorHandler does not attempt any local redeliveries. You have to configure it to do so, for instance to set a maximum redelivers to a number > 0.
See Transactional Client for more.

See also

Full detail can be found here.

Total visitors since Jan 2012

World Visitor Map