Oracle ASP.Net membership provider ProviderUserKey endian conflict

I recently ran into an issue where the ASP.Net membership method ProviderUserKey() was returning the UserID with the first eight characters scrambled in their order.

It really perplexed me until I discovered that there is a concept called Endian. The term Endian comes from Swift’s Gulliver’s Travels:
“The Lilliputians, being very small, had correspondingly small political problems. The Big-Endian and Little-Endian parties debated over whether soft-boiled eggs should be opened at the big end or the little end.”

In computer terms big endian and little endian refer to which bytes are most significant in multi-byte data types. It describes the order in which the sequence of bytes is stored.
IBM mainframes use a big endian architecture, whereas x86 computers use a little endian architecture.
This conflict is often referred to as the NUXI problem. For the word UNIX in a big endian system would be stored as UNIX, whereas on an x86 system (little endian) it would be stored as NUXI).
Our Oracle 11 database runs on UNIX, so to convert the big endian UserID to a little endian UserID the following method was created which resolves the issue for me:

public static string TranslateOraceEndianUserID() 
    { 
        MembershipUser myObject = Membership.GetUser(); 
        Guid g = new Guid(myObject.ProviderUserKey.ToString()); 
        byte[] b = g.ToByteArray(); 
        string UserID = BitConverter.ToString(b, 0).Replace("-", string.Empty); 
        return UserID; 
    }