EASI ID (pt. 2)

Back in March, I posted EASI ID (pt 1.5), posting a question about who owns the rights to resources within a namespace, specifically email addresses.  The reason was to stimulate some braincells, about what could happen if users chose to protect personal content with a digital identity that they thought they owned, but which later they found out the didn’t (in this case their work email address).

Ariel Gordon, one of the rock stars on the Microsoft Identity Strategy team (along with Kim Cameron and others…), recently posted this comment:

Ariel Gordon said

August 7, 2009 at 2:34 pm e

Contoso owns the domain and any identifier in its realm.
Email addresses bear a claim of employment. I.e. my @contoso.com address shows (with a certain level of certainty) that I work for Contoso. Using this address after I leave the company is akin to keeping distributing business cards with the address on it.

Today, 99% websites leverage email providers’ infrastructure for user authentication: you type your email address as a login then create a password that can be reset/resend via email, effectively handing the keys to the account to anyone who controls the mailboxn including the new guy–Jerry Smith in your example.

Websites who implement authentication delegation (aka federation in the consumer sense of the term), could be informed by the IdP of user account deprovisionning and, as best practice, take action to close the account, prompt the user to create alternate credentials (if they have a fallback email address or phone #), etc.

Thoughts?
-Ariel.

I started to reply with a bit of the backstory in the comments, but figured I’d give this it’s own post, if for no other reason than (I think) it’s a fun look into some of the dynamics of digital identity…not to mention internal politics… So here is my response:

 

Hi Ariel!

Thanks for replying.  Yes, you’re correct, this is exactly what happens, and I agree with you.

The motivation for this post, was a series of conversations that I was in with an internal group here at Microsoft, about who "owned" the @microsoft.com namespace for user identities.  Historically, the internal identity management team has owned corp.microsoft.com, but the actual microsoft.com namespace was owned by the team that supports the www.microsoft.com website.  However, way back when, somebody in the Live ID team also decided that the microsoft.com namespace was theirs (in the Live ID sense)

It turns out, that today, there are approx. 2.5 million Windows Live ID’s in the @microsoft.com namespace.  Obviously we haven’t had that many employees.  But back in the day, there was a time when the Live ID team believed that @microsoft.com would be a good namespace for customers to use, similar to @hotmail.com or @live.com.  This isn’t really as crazy as it sounds, because it’s analogous to users creating a Yahoo ID in the @yahoo.com namespace. 

However many years later though, as we enter the age of federation, the challenge is that Microsoft Corporation uses @microsoft.com as our corporate namespace.  In contrast, Yahoo Corporation uses @yahoo-inc.com for their corporate email addresses.  So Yahoo can choose to give @yahoo.com to their customers, whereas Microsoft had a conflict.

This was a fun debate at the time, and ultimately we came to the decision that @microsoft.com is our corporate identity.  The question though, of what should come to those 2.5 million user ID’s.  Fortunately the Live ID team has the solution for this, and added a flag into the federation setup so that a company can choose to “evict on reserve” or “allow merge” of any existing users when they federate.

Allow Merge means that anyone with an existing user account in a namespace that’s federated, will have the option of associating their existing WLID with their new federated ID.  In Live ID speak, it means they keep the same PUID.  The result is that you keep anything you had access to, but you do so with your new corporate-account-backed, federated Live ID rather than your older, separate username/pw WLID.

Evict on reserve is just what it sounds like, where any user accounts which exist in a namespace when it’s reserved, will be moved into a “forced rename” state.  This means that the next time the user logs on with their separate user name and password, they will be forced to change their user name (keeping the same account/PUID) to a different email address, one which is hopefully their personal address.

For Microsoft employees, we chose evict-on-reserve, and are in the process of working through the details of implementation.  Our thinking behind this, is that even though they are in the @microsoft.com namespace, any existing accounts are all “personal use” accounts.  Therefore, we should protect the personal data, and have a user rename their account to a personal account.  When a user logs in with their “new” federated @microsoft.com account, they will be doing “business” work with an account that is backed by their corporate credentials (and which goes away when their employment ends).  And yes, we’re working with the Live ID team to get some controls put in place for companies that federate, so that they can limit where corporate backed WLID’s are used.

So that’s where we’re at.  Hopefully this gives other folks who are federating something to think about as well, as they integrate with service providers such as Live ID.

I’d love to hear what you, or anyone else thinks about these fun, “moving to the cloud” challenges!

~Brian

Federation Services and Direct Access

Now here’s an interesting combination.  What do you do when you have a service which has both an internal and internet facing components, with different behavior for each, and then you deploy Direct Access?

Quick aside:  For those not aware, Direct Access is a feature which allows domain joined Win7 laptops to behave as though they were on the corporate network and have full access to internal resources, regardless of where they are.

The important detail here, is that one of the control mechanisms is an idea of split DNS.  Internal domains are flagged as such, so that clients route that traffic internally, and everything else is considered “internet”.

So the question is, if you have your ADFS servers deployed in a unique namespace (we use *.sts.microsoft.com), then do you call that an internal namespace or an external one?  I’m not sure of the right answer at this point, but I’ve been bouncing around and just recently (this past week) requested a change.

Another quick note:  Remember, that we’ve got ADFS deployed so that users who are on corpnet get integrated authentication – no prompts – when they hit the ADFS servers.  Users on the internet get forms based auth, and have to enter credentials

So for your DA users, what kind of experience should they have?  Initially, when we first started rolling out DA, it made sense to me that DA enabled clients on the internet should have the “corpnet” experience.  In other words, even though I’m at home, I should still get integrated authentication. 

Just recently though, we ran into some issues where DA enabled users would be in situations (client issues, behind firewalls, etc…) where they were able to traverse the internet but were not able to get the DA connection back to corpnet.  In these cases, users were actually able to hit the internet based, federated resource.  But because the client thought that the ADFS servers were internal (and DA wasn’t working), they were failing to authenticate.  They could see the app, just not get into it.

So we had the DNS policy on DA clients changed, and now our DA clients believe that the ADFS servers are external.  This takes us back to our pre-DA behavior, where clients physically on corpnet (DA or not) will get integrated auth, but clients on the internet (DA or not) will always get FBA.  At least with FBA though, they can get access to the resources.

The change hasn’t been in place long enough, and we don’t have a critical mass of users on our DA pilot yet, so I haven’t heard the rumblings about the change to see whether anyone has noticed. Yet.  I’m sure this won’t be the last time we need to think about ADFS and DA, but all other things considered, right now I think the best thing to do is keep the 2 separate.

PoSH for ADFS

* This post applies to the Beta 2 release of ADFS and may or may not apply to the final product *

Some useful snippets from the ADFS/PowerShell world  (by no means exhaustive, just enough to get you going):

PS C:\Users\bpuhl> get-pssnapin -registered

Name        : Microsoft.IdentityServer.PowerShell
PSVersion   : 1.0
Description : This powershell snap-in contains cmdlets used to manage Microsoft Identity Server resources.

PS C:\Users\bpuhl> get-pssnapin -registered | add-pssnapin
PS C:\Users\bpuhl> get-command get-GS*

CommandType     Name                                                Definition
———–     —-                                                ———-
Cmdlet          Get-GSAttributeStore                                Get-GSAttributeStore [[-Name] <String[]>] [-Verb...
Cmdlet          Get-GSCertificate                                   Get-GSCertificate [[-CertificateType] <String[]>…
Cmdlet          Get-GSClaimType                                     Get-GSClaimType [[-Name] <String[]>] [-Verbose] …
Cmdlet          Get-GSDelegate                                      Get-GSDelegate [[-Name] <String[]>] [-Verbose] [...
Cmdlet          Get-GSEndpoint                                      Get-GSEndpoint [[-Address] <String[]>] [-Verbose...
Cmdlet          Get-GSIdentityProvider                              Get-GSIdentityProvider [[-Name] <String[]>] [-Ve...
Cmdlet          Get-GSInformationCard                               Get-GSInformationCard [[-CardName] <String[]>] [...
Cmdlet          Get-GSProperties                                    Get-GSProperties [-Verbose] [-Debug] [-ErrorActi...
Cmdlet          Get-GSProxy                                         Get-GSProxy [-Verbose] [-Debug] [-ErrorAction <A...
Cmdlet          Get-GSProxyProperties                               Get-GSProxyProperties [-Verbose] [-Debug] [-Erro...
Cmdlet          Get-GSRelyingParty                                  Get-GSRelyingParty [[-Name] <String[]>] [-Verbos…

PS C:\Users\bpuhl>

But I will throw out one really useful tidbit for those of you who are playing with the proxy component of the ADFS beta release and are pulling your hair out trying to get it to talk back to your full server (this is assuming you’ve already got the proxy certificates in place):

Disable CRL checking on STS servers

set-gsproperties –proxyCertRevocationCheck “None”

Even if you have access to the CRL’s and everything *should* work for you.  In the Beta release, you need to disable CRL checking on the proxy certificate…

Laura’s Rule for ADFS Troubleshooting

“If your ADFS is broken, it’s PKI. If it’s not PKI, you’ve got a typo. If it’s not a typo, it’s PKI.” – Laura Hunter

ADFS Event ID 111

Event ID 111 is a useful one to recognize when you’re scrolling through the logs of your ADFS server.  It will look something like this:

Log Name:      Application
Source:        GenevaServer
Date:          8/5/2009 3:27:35 PM
Event ID:      111
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      RED-ADFS-05.redmond.corp.microsoft.com
Description:
The Federation Service encountered a serious error while processing the WS-Trust request.
Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue

Additional Data
Exception details:
System.IdentityModel.Tokens.SecurityTokenValidationException: ID4063: LogonUser failed for the ‘1234@windows.microsoft.com’ user. Ensure that the user has a valid Windows account. —> System.ComponentModel.Win32Exception: Logon failure: unknown user name or bad password
   — End of inner exception stack trace —
   at Microsoft.IdentityModel.Tokens.WindowsUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)
   at Microsoft.IdentityServer.SecurityTokenService.MSISSecurityTokenService.BeginGetScope(IClaimsPrincipal principal, RequestSecurityToken request, AsyncCallback callback, Object state)
   at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.BeginIssue(IClaimsPrincipal principal, RequestSecurityToken request, AsyncCallback callback, Object state)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.DispatchRequestAsyncResult..ctor(DispatchContext dispatchContext, AsyncCallback asyncCallback, Object asyncState)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginDispatchRequest(DispatchContext dispatchContext, AsyncCallback asyncCallback, Object asyncState)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.ProcessCoreAsyncResult..ctor(WSTrustServiceContract contract, DispatchContext dispatchContext, MessageVersion messageVersion, WSTrustResponseSerializer responseSerializer, WSTrustSerializationContext serializationContext, AsyncCallback asyncCallback, Object asyncState)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginProcessCore(Message requestMessage, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, String requestAction, String responseAction, String trustNamespace, AsyncCallback callback, Object state)

System.ComponentModel.Win32Exception: Logon failure: unknown user name or bad password
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="GenevaServer" />
    <EventID Qualifiers="0">111</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0×80000000000000</Keywords>
    <TimeCreated SystemTime="2009-08-05T22:27:35.000Z" />
    <EventRecordID>601453</EventRecordID>
    <Channel>Application</Channel>
    <Computer>RED-ADFS-05.redmond.corp.microsoft.com</Computer>
    <Security />
  </System>
  <EventData>
    <Data>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</Data>
    <Data>System.IdentityModel.Tokens.SecurityTokenValidationException: ID4063: LogonUser failed for the ‘1234@windows.microsoft.com’ user. Ensure that the user has a valid Windows account. —&gt; System.ComponentModel.Win32Exception: Logon failure: unknown user name or bad password
   — End of inner exception stack trace —
   at Microsoft.IdentityModel.Tokens.WindowsUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)
   at Microsoft.IdentityServer.SecurityTokenService.MSISSecurityTokenService.BeginGetScope(IClaimsPrincipal principal, RequestSecurityToken request, AsyncCallback callback, Object state)
   at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.BeginIssue(IClaimsPrincipal principal, RequestSecurityToken request, AsyncCallback callback, Object state)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.DispatchRequestAsyncResult..ctor(DispatchContext dispatchContext, AsyncCallback asyncCallback, Object asyncState)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginDispatchRequest(DispatchContext dispatchContext, AsyncCallback asyncCallback, Object asyncState)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.ProcessCoreAsyncResult..ctor(WSTrustServiceContract contract, DispatchContext dispatchContext, MessageVersion messageVersion, WSTrustResponseSerializer responseSerializer, WSTrustSerializationContext serializationContext, AsyncCallback asyncCallback, Object asyncState)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginProcessCore(Message requestMessage, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, String requestAction, String responseAction, String trustNamespace, AsyncCallback callback, Object state)

System.ComponentModel.Win32Exception: Logon failure: unknown user name or bad password</Data>
  </EventData>
</Event>

What makes it interesting, is that this is the same as the server saying, “Oh Snap! Something just happened and I don’t know what that was!”

In this case, you can look at the event data in a little more detail, and pretty clearly see what happened.  But you do need to check these out. 

When we first upgraded our production ADFS servers to the Beta 2 release, we found that nearly all of our claims processing rules were sending multiple identity claims to the relying parties.  We were throwing Event 111 on nearly every authentication, and had to go in and correct the claims rules for each one to get the errors to go away.

Finding the SQL server ADFS is using

* This post applies to the Beta 2 release of ADFS and may or may not apply to the final product *

 

This was harder than I thought it should be, until I found out that there aren’t 2 administrative interfaces for ADFS, but rather there are 3!  You can either use the console on the ADFS server itself, the Powershell commandlets, or you can use WMI to gather data about the server. 

So if you want to figure out which SQL server your ADFS web server is using as it’s policy store, here you go:

PS C:\> Get-WmiObject -Namespace "Root\MicrosoftIdentityServer" -class SecurityTokenService
__GENUS                          : 2
__CLASS                          : SecurityTokenService
__SUPERCLASS                     :
__DYNASTY                        : SecurityTokenService
__RELPATH                        : SecurityTokenService=@
__PROPERTY_COUNT                 : 3
__DERIVATION                     : {}
__SERVER                         : DSP20A61
__NAMESPACE                      : Root\MicrosoftIdentityServer
__PATH                           : \\DSP20A61\Root\MicrosoftIdentityServer:SecurityTokenService=@
EventLogLevel                    : 63
PolicyStoreAdministrationAddress : net.pipe://localhost/policy
PolicyStoreConnectionAddress     : Data Source=DSP20A61\SQLEXPRESS;Initial Catalog=GenevaPolicyStore;Integrated Security=True

Yes, I have asked that this specific bit of information be made slightly more accessible, so the request is in.  We’ll see if it makes the cut when the product ships, but more important is to know that in general, you can use WMI to get at some of the configuration information.

Active Directory Federation Services (the server formerly known as Geneva)

Ok, so it’s old news, but I had to start somewhere and this is as good a place as any.  A couple weeks ago at the Worldwide Partner Conference, some naming announcements were made, you can read about them here:  http://blogs.technet.com/forefront/archive/2009/07/13/business-ready-security-news-at-wpc.aspx

Most relevant to me, is that Geneva server is now officially called Active Directory Federation Services.  In fact, from the article, the 3 distinct components are:

· Active Directory Federation Services – formerly known as “Geneva” Server

· Windows Identity Foundation – formerly known as “Geneva” Framework

· Windows Cardspace – same as current version

So since it’s still going to be called ADFS, then I don’t need to change my blogging tags (yippee!).  So here comes the flurry of ADFS related posts, basically from the trenches of the past year or so of dogfooding the server formerly known as Geneva Server.

Enabling Logging in ADFS

* This post applies to the Beta 2 release of ADFS and may or may not apply to the final product *

 

In ADFSv1, the logging was enabled in the UI.  You checked the checkboxes, set a log file path, and left it alone.  In fact, in the MSIT deployment, we were in the habit of running with full logging enabled all the time, letting them wrap on their own, and accepting the imperceptable performance hit because we didn’t have that much load.  The latest version of ADFS is a different beast though.  In addition to being a much richer product from a feature/functionality perspective, there is much more logging which can be enabled for an administrator to use in troubleshooting.

To enable logging, start by opening the web.config file (located in the c:\inetpub\IdentityServer\WSFederationPassive.Web directory) and scrolling towards the bottom.  You’ll see a section which looks like this:

<system.diagnostics>
  <sources>
    <!– To enable tracing on a particular component, uncomment the desired section below. Then uncomment
         the shared listener named "xml" and the Microsoft.IdentityServer.SourceSwitch in the switches element.
     –>
    <!– Federation passive related tracing
    <source name="Microsoft.IdentityServer.Shared.WSFederation" switchName="Microsoft.IdentityServer.SourceSwitch" switchType="System.Diagnostics.SourceSwitch" >
      <listeners>
        <add name="xml" />
      </listeners>
    </source> –>
  </sources>

  <!– This is the shared listener for all of the tracing.  All of the sources write to this listener.
       If you want a more fine-grained listener, one can be added to the listeners element in each source above, which
       can then output to different files if desired. After uncommenting this, put the absolute path of the trace file
       ie c:\temp\TraceData.svclog.  Be sure that the identity of the service can write to the file and directory –>
  <sharedListeners>
    <!– <add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="" /> –>
  </sharedListeners>
  <switches>
    <!– Uncomment this switch to use with your trace sources.  You can add more and configure
         them per source by editing the value attribute.  For each source above, there is a switchName
         attribute that links the source to a switch in this collection.  You can use the same switch
         with every source, or you can create a different switch for source for more control if thats
         desired.
    <add name="Microsoft.IdentityServer.SourceSwitch" value="Information" />
    –>
  </switches>
  <trace autoflush="true" ></trace>
</system.diagnostics>

To enable tracing, you want to do a few things (basically following the instructions in this section):

1)  Uncomment the tracing that you’re looking for – being careful to keep the comments/instructions commented out (yeah, I’ve blown that at least twice)

2)  Uncomment the <sharedListeners> tag, and if you like, add a path to the initializeData field.  We usually use d:\logs

2a)  Make sure that the account ADFS is running under, either NETWORK SERVICE or a system account, has write access to that directory (yeah, blown that one before too)

3) Uncomment the <add name= tag, and we usually change the value to “Verbose”

At this point, you should see the log file, something like TraceData.svclog.  If you open it up in notepad.exe, you’ll find a horrendous jumble of unformatted XML which is nearly indecipherable by humans.  So I highly suggest you use a utility, such as svcTraceViewer.exe, which is available when you install Visual Studio 2008 [1], and which provides a much, MUCH better experience parsing the logs.

Good luck, and happy federating!

~B

 

 

[1]  Personally, I’m not a huge fan of needing a utility that’s only available in VS2008 to read these things, because as an IT admin I don’t normally need developer tools like Visual Studio.  I would love to post a copy of it for those that don’t have access/ability to get it from a VS2008 install, but I can’t get a definitive answer on redistribution rules, and as an MS employee I’m not risking my job over it…  I’m happy to host any comments from the readers who want to help others with utilities for reading these things.

 

Oh yeah, one more thing…  don’t leave the logging turned on all the time.  Just enable it when you need it, and then disable it.  Came back to a server a few days later to find a 1.5GB log file that was just growing and growing…

Random port? I think not…

6 months ago – We’re in the process of federating with a new partner, and the link they send us to their federation server looked something like this:  https://federation.foo.com:9031/blah – notice the port 9031?

This seemed a little random, but not completely unusual since people tend to grab an available port when they want to host a test/beta site.

With a bit of troubleshooting, working with our proxy server team, etc… figured out that our proxy servers only allow SSL connectivity out to port 443, so the federation was broken.  A bit of back and forth with the partner, they moved to the standard SSL port, and everything worked great.

4 months ago – We’re in the process of federating with a new partner, and the link they send us to their federation server looked something like this:  https://federation.contoso.com:9031/blah

Us:  Hey, we’ve seen this before – we can only connect to port 443 for SSL sites, can you move your federation server to the standard port?
Reply:  Sure, done – check it now

And there was much rejoicing. yeah.

Rinse and repeat this a half a dozen times over the past few months, and we’re getting pretty good at recognizing the issue.  And since about 60% of our federation partners are using STS’s which are not ADFS/Geneva, this scenario is even more common.

The other day, while dancing this dance yet again, we did notice one thing though – It’s not a random port – it’s ALWAYS port 9031.  Not only that, but looking back, it’s always with partners who are using Ping Federate server.

A quick search for “9031” on the Ping website, finds that a lot of their sample code uses port 9031. 

Ah ha!  Now I get it.  It wasn’t random after all, but rather re-using the sample code to set up services.  Which is a great, so now we know that when we’re federating with a partner that’s using Ping Federate – be on the lookout for port 9031.

Collection agencies….

I have had a few discussions recently at work about ways to make things more convenient.  Either convenient for our users (cloud services), convenient for our customers (single sign on), etc… 

But a one-two punch hit me, when I just had 2 close friends – both of whom have been impacted by the financial mess – have their identity attacked because something that had built in security controls (checks) was made to be more convenient (by phone), and in the process all of the controls were removed so my friends were vulnerable.

Really, I call it fraud, or identity theft, or just plain robbery…  But in both cases, the banks say that there are no laws against this:

My friend lost her job, and fell behind on payments.  She owed $1100 for this months rent, $4400 to a creditor that by this point had gone to a collection agency, and some other bills (credit cards, gas, electricity, etc…).  Through creative budgeting and working with parents, friends, and anyone else, she scraped together $5000 that she could use. 

With the new money available, she came up with the following plan:

   $1100 for rent
      900 for the other bills
      500 to the collection agency
      The rest to be used for the following months rent, payments, etc…

She called the collection agency, and agreed to pay them $500 now, and then set up a payment plan for the rest of the money.  That’s where the first mistake happened:  They wanted the payment as a “check by phone”.  So she voided a check, gave them the info, etc…

The collection agency first attempted to clear the check for the full $4400.  Because the money was in the account, the check cleared – of course, this meant that she couldn’t pay any of the other bills, or her rent, etc…  And she had already tapped out her friends, parents, etc…

You can imagine that the calls to the collection agency were like:  “Sorry, sucks to be you – we’ve got our money now”

The bank was equally useless:  “You gave them a check by phone, the money was in the account, they cleared it…Sucks to be you”

This was just completely ridiculous, but it shows that in the absence of standards or protocols, there is no shortage of people that will offer things for the sake of “convenience” which blow the hell out of “security”.  If you have to write a check and sign it, then you fill in the amount, etc…  modification of that is check fraud.  But those security controls went out the window when banks allowed people to do “checks by phone”, and there is absolutely nothing to prevent unscrupulous people from raping your bank account if you give them the information.

The second case is similar, but with a slight twist

My friend has slowly but surely been paying off debts that were racked up over a period of time, and has been working through one of those debt consolidation management companies.  Since she wasn’t getting the resolution that she needed from the company, she took back the money that was in their escrow account and started working with the collection agency independently.

On the first phone call, she had an $7,000 debt and worked with the agency to negotiate down to where they would accept $4300.  Seems like a good deal, so again, check by phone for $4300.

A couple of days later, she received a notice from the collection agency, indicating that they “Had an agreement for an initial payment of $4300”.  In other words, the deal they made on the phone was a lie, instead of negotiating the total, they just wanted an initial payment and were going to keep going after her for the remaining balance.

Ahhh…but the check by phone hadn’t cleared yet.

So a quick call to the bank, a $28.00 stop payment charge, and there was a stop-payment for that check before it cleared.

Good right?

Not so much.  2 days later, $4300 was withdrawn from the account anyway, by check #1001 (not the check number she gave them).  A long, convoluted, multi-transfer call back with the bank this time, and they could see where the initial check number had attempted to clear, been rejected (the stop payment), and then the company had re-submitted another check by phone with the different check number and got the money.

After several days of arguing, it’s still unclear whether the bank is going to say “Sorry, sux to be you” or if they are actually going to help.  I’m not holding my breath.

So again, the safety features around checks – being numbered, signed, amounts written (twice) – are all placed into the trusting hands of the least trustworthy person (the merchant that wants your money), and there is remarkably little recourse.  I suppose you could go get a lawyer, etc…  But during that time the money is gone, life still needs to be lived, and a lawyer is going to take 30% of whatever you get back anyway (or some amount of payment)…

All for the sake of convenience (to whom?)

There are better ways, one of which I really like.  I’ve had a credit card with CitiBank since college.  And many years ago, they came up with this idea of virtual account numbers for your credit card.  You can go to their website (or they have a downloadable application), and if you want to make a purchase, you can get a one-time use credit card number (with expiration and CVC) for that one purchase.  I haven’t used it in a while, but IIRC you can even specify the amount of the purchase you’re going to make (which is really the protection).  This is great, because the security of a credit card is handing the piece of plastic with the signature on the back to the person behind the register.  With online purchases, you can’t do that, so instead lets take the things which you can control (amount of purchase, usefulness of the number after it’s been used properly) and control those instead.  Reasonable mitigations.

This is the type of control that we’re going to need if we want to protect our resources in a more “convenient” (read: Online) world.