• Ripple (unregistered)

    While much of this banter is technically correct, the article and critique falls well short of the mark. Those of us in I.T. can certainly see the limitations of such an implementation but isn't that the case with practically any implementation.

    The goal of multi-factor, or even any factor, authentication is to make entry into one's data more difficult. Nothing is purely secure because items can be stolen, private information can be learned and all information can be socially engineered if enough care is taken.

    Having worked for multiple financial institutions and with multiple processors, I do understand both sides of the equation. In most cases, it is going to take more than 10 years in I.T. (which this author has) to be able to understand the issues this author has. Well, it shouldn't but it many cases it does because the inability to process objectively.

    The best two factor implementations aren't practical for most FIs, especially credit unions. Many CUs had problems with even this type of implementation but mostly due to lack of planning, customer/member awareness and foresight. If done properly, while it still generates many calls, the "storm" is quick and largely a non event.

    Multi factor authentication, even in this overly simplistic form still requires more effort and difficult towards gaining access. Combined with back-end automation that locks out accounts for improper entry, the ability to customize questions beyond the many times absurd standard questions and a campaign of customer awareness, the resulting implementation is far better than a standard 4 digit pin code.

    Anyone that understands largely unintelligent attacks understands very well that it is difficulty and layers that are some of the most important aspects of thwarting the attack. Similar to securing your house and leaving the light on before leaving on an extended trip. A little protection goes a LONG way.

    Most phishing attacks are unintelligent and online banking fraud is largely represented by single cases, not en masse. And in a large majority of these cases, it is performed by a relative, son/daughter or sibling.

    These implementations are no different than other evolving standards that are rushed out ... works in progress.

    And keep in mind that while ATM/Debit cards are still the primary method for obtaining "secured" and authenticated access to cash, I know people that are well schooled in I.T. and challenge devices that keep their PIN numbers for those cards with the card. Many, many still practice that "art".

    This article is too one side, subjective and one dimensional to provide any worthwhile insight.

  • DotnetLog.com (unregistered)

    I thought it was only me who thought the system was so great!! BTW: mine times out if you aren't fast enough to click the passwords

  • Stupid Bank's customer (unregistered)

    The 2 factor login does nothing that a much longer and more complex password won't do.

    So how do I know the login screen is from the bank? It could be one of them phishing sites.

    ING Direct ask you for User ID then it authenticate to you by showing a picture and catch phrase you have chooses, then ask you for password. etc

    Worse case is that you gave a phishing site your userID and may be your secret of enjoy running around naked.

    My other bank asked stupid questions that are too specific - 40-60% of them assume you are married, have kids, but still have living grandparents. If you hate sports, then the other 20% of them are gone.

  • Heston (unregistered)

    I don't think anyone has said it yet, but I think the reason why RED and other short strings are disallowed is that three-character strings are too easy to autoguess.

  • Harlan (unregistered) in reply to Heston

    Can't WTF be sued for some reason over this article? I was just wondering, I thought shitty software companies all spent millions of dollars on lawyers to hide the deficiencies in their systems instead of hiring better software people.

  • Jim Bob (unregistered) in reply to Heston
    Heston:
    I don't think anyone has said it yet, but I think the reason why RED and other short strings are disallowed is that three-character strings are too easy to autoguess.

    read the article dick smoker, it says it in the god damn article

  • Jim Bob (unregistered) in reply to Ripple
    Ripple:
    While much of this banter is technically correct, the article and critique falls well short of the mark. Those of us in I.T. can certainly see the limitations of such an implementation but isn't that the case with practically any implementation.

    The goal of multi-factor, or even any factor, authentication is to make entry into one's data more difficult. Nothing is purely secure because items can be stolen, private information can be learned and all information can be socially engineered if enough care is taken.

    Having worked for multiple financial institutions and with multiple processors, I do understand both sides of the equation. In most cases, it is going to take more than 10 years in I.T. (which this author has) to be able to understand the issues this author has. Well, it shouldn't but it many cases it does because the inability to process objectively.

    The best two factor implementations aren't practical for most FIs, especially credit unions. Many CUs had problems with even this type of implementation but mostly due to lack of planning, customer/member awareness and foresight. If done properly, while it still generates many calls, the "storm" is quick and largely a non event.

    Multi factor authentication, even in this overly simplistic form still requires more effort and difficult towards gaining access. Combined with back-end automation that locks out accounts for improper entry, the ability to customize questions beyond the many times absurd standard questions and a campaign of customer awareness, the resulting implementation is far better than a standard 4 digit pin code.

    Anyone that understands largely unintelligent attacks understands very well that it is difficulty and layers that are some of the most important aspects of thwarting the attack. Similar to securing your house and leaving the light on before leaving on an extended trip. A little protection goes a LONG way.

    Most phishing attacks are unintelligent and online banking fraud is largely represented by single cases, not en masse. And in a large majority of these cases, it is performed by a relative, son/daughter or sibling.

    These implementations are no different than other evolving standards that are rushed out ... works in progress.

    And keep in mind that while ATM/Debit cards are still the primary method for obtaining "secured" and authenticated access to cash, I know people that are well schooled in I.T. and challenge devices that keep their PIN numbers for those cards with the card. Many, many still practice that "art".

    This article is too one side, subjective and one dimensional to provide any worthwhile insight.

    Anyone with 2 programming classes from the local community college can understand the limitations in this article. Clearly you are part of the problem with your apologetic attitude towards the scamsters who are selling this shit software.

  • Susan (unregistered)

    I find this absolutely hilarious! Simply because the Credit Union in question...Synergy One, DOES NOT have the Cavion Consumer Internet Banking platform! Nor do most of the credit unions you sited in the article.

    Appears there is a liable suit just waiting to be started here. You have lost all credibility.

    SHAME ON YOU. I think you need to check your facts MUCH better next time.

  • From a Banker (unregistered)

    The one thing all the "wish it was two-factor" bashing misses is the average Joe factor. The average Joe does NOT want an extra "thingy" or biometric device or whatever to authenticate himself online. The amount of complaints we got just implementing mutual authentication (the image you select for yourself so later you know you're not on a phishing site) was staggering, but at least we were able to get that done. Implementing two-factor authentication to the average Joe would put us out of business. While the crowd here is aware of the increased risk, the average Joe doesn't - and doesn't care to know, I'm sad to say.

    If you want to complain effectively, talk to your lawmakers (Congress). Until a law is passed that REQUIRES two-factor implementation (instead of simply a risk analysis be done regarding it), banks generally won't use it - competition from other banks who stay "convenient" with wish-it-was-two-factor would prevent it. Complaining to your bank is WRONG TARGET. As an IT staff, I would love to put in two factor. THEY WON'T LET ME, for the reasons cited above. It's that simple. And if I did, the bank would close and I'd become unemplyed. It's a case of being punished if you do the right thing.

    CAPTCHA: smile - trying despite it all.

  • From a Banker (unregistered) in reply to Eso

    "But if I want to make any money transfer after login, single-use security code is sent to my cell phone via SMS and I have to enter it to web page to confirm transaction. This code is valid only for this specific session. "

    The cell phone idea is cool - "out-of-band" authentication at its best! And probably much better that two-factor in any case.

  • Sean (unregistered)

    My bank (T&C FCU) uses this system, too. I've been bitching about it for years as the system as a whole is a piece of crap in many other ways. This was just icing on the cake.

    I'm emailing the bank my 83rd complaint against the software, along with a link to this article.

  • Ripple (unregistered) in reply to Jim Bob

    Yeah, that's it "Jim Bob" ... you got me. How naive are you really? You OBVIOUSLY don't know the first thing about business, which is what limits so many coders. I have worked formally in I.T. for over 20 years and was coding long before that as well. It is all too easy to take a look at an implementation and fill it with holes, especially one like that. I could easily shoot these implementations so full of holes that they would never get off the ground.

    Your lack of knowledge regarding business implementation, strategy and and regulation is blinding you. Somewhere in between true multi factor authentication and effective end-user implementation is a process/functionality that will provide a reasonable level of security over and above what has been expected. I could just see mass issue of biometric devices and fobs to 65+ year old customers.

    What interests me is not first generational implementations, but evolution of both regulation and implementations that address both customer needs and regulatory mandates (towards addressing those issues that customers don't even know they need).

    This has ZERO to do my apologetic attitude towards the producers of the software and everything to do with the first attempt at addressing the issue. I do not work for these organizations that develop the software but I understand not only their customers but also their processes and challenges.

    Instead of showing your complete lack of knowledge on the subject, how about instead use this as a homework project ... objectively. You are a large financial institution software provider and have many large host based applications used by FIs to service clients both young and old. You have been given essentially 18 mos. to roll out an entirely new paradigm from what has gone before to help secure online banking platforms. It must be cost effective for small institutions and large ... because it is mandated federally. And it also must be adoptable and easy to use so as not to confuse the customer base. Figure, too, that the remote users that use the software are not local to the institution ... read that as 50% of the customer base is remote. Now, go design that system Jim Bob.

    Apologies to other readers here but this type of discussion is why coders and software engineers get themselves in so much trouble in the business world ... they don't understand business analytics and implementations. Most program blindfolded without the first idea as to what the variables are.

  • Tom Dejoria (unregistered)

    You are all right that these are piss poor solutions. But allow me to explain why we are where we are today. FYI- I am a security professional well entrenched in the Credit Union/Community Bank industry.

    Several years back security consultants successfuly convinced the federal banking regulators (FFIEC) that user ID/PW was grossly insufficient. This was a good thing!

    But what occurred was not. A regulatory requirement was forced on ALL financial institutions, stating that every institution must a risk assessment of their online systems and determine if a solution such as strong authentication was necessary. Yes it was vague like this. No it did not say you had to implement 2-factor.

    Welcome Consultants!!! Security consultants across the country were telling the banks that this meant two factor authentication or strong authentication and that it was mandatory; a slight misinterpretation of the reg.

    At the time there were not many publicly known solutions other than tokens like RSA and Safeword. Neither of which would work for an institution with tens of thousands of users and typically 3-5 people running IT. Too costly, way too expensive, and too much overhead. The existing solutions were simply not compatible for the need.

    So the regulator's mandate came out in October of 05 with a deadline for response by the end of 06'. Next thing you know, there were a half dozen solutions on the market. PassMark, Cyota, etc. Most of these solutions sucked. Some were pretty decent.

    Problem is it was a race to the market! Every credit union began looking at solutions. the vendors were responding to them, but what they didnt realize is that the institutions were also going to their online banking vendor asking for them to address it.

    So the market went from 20,000 institutions, down to about 12 online banking vendors. They made the decision for the insitituions. And this was based primarily on who got to them first, who had the best story (BofA just bought our solution!), and what price could be negotiated.

    It was mostly about money and very little performance. As long as it would integrate, they trusted the company's word that it was "the most secure solution on the market".

    Some companies like Cavion Built their own. As if they have the expertise to be doing so.

    In my opinion, Q&A solutions are no better than UID/PW solutions. People are being phished for this info right now today!

    On the positive side, a recent survey shows that ~80% of institutions will be re-evaluating these solutions in 2008.

    Get ready for something new and as mentioned above, COMPLAIN if you dont see something better.

  • Tom Dejoria (unregistered)

    Oh yeah!

    I also really like the out-of-band SMS concept that that BofA and HSBC have deployed. You will be seeing a lot more of this in the very near future. Problem is it will remain optional since not every consumer (believe it or not) has a cell phone. Think people over 70 that dont understand any of this.

  • curtmack (unregistered) in reply to Doug
    Doug:
    So how do we have the software verify that we HAVE something. odds are no matter what we have it just produces a code that then gets transmitted. Can't that just always be replicated some how?

    I remember reading about it. This sort of system has a name, but I don't remember what it is... basically, the server sends some random sequence, then both server and client (in this case the device) encrypts that sequence via some nonreversable algorithm using the security code as a key. The client sends the result, and if they match, you're in. The actual security code is never sent, not even to the host machine, so the system is much more secure.

  • radix (unregistered) in reply to scav

    nope, there`s a toUpper - conversion at the beginning of the script.

  • (cs) in reply to Ripple
    Ripple:
    Having worked for multiple financial institutions and with multiple processors, I do understand both sides of the equation. In most cases, it is going to take more than 10 years in I.T. (which this author has) to be able to understand the issues this author has. Well, it shouldn't but it many cases it does because the inability to process objectively.

    The best two factor implementations aren't practical for most FIs, especially credit unions.

    <etc etc>
    Hair, meet ass. Ass, meet hair. Vertically.

    (Apologies to Lily Tomlin for ripping this one off.)

    This author has ten years in I.T., whatever that is, and I'm willing to bet that it didn't start with QBasic on an Atari.

    I've got twenty years in I.T. (whatever that is), and I've worked on credit card and banking systems.

    Alex probably has at least ten years in "I.T." (can we spell that again, kids?).

    OK, we're all even at the starting line here. Now, tell me, what is Alex's basic point?

    Don't know? Bzzzt. There's a whole ten years of "I.T." down the drain.

    Had you been paying attention, you would have noticed a perfectly reasonable argument. Which is: there is a federally mandated requirement for "two factor" authentication, and that most financial institutions are bolloxing it up.

    Why you should do it, how you should do it, and when you should do it are probably irrelevant.

    Basically, it's a stupid law, and it's stupidly "implemented."

    Bring on the stupid lawyers. But less of this "I've been doing this for ten years" crap, please.

    Tom Dejoria:
    You are all right that these are piss poor solutions. <etc etc>
    Now, this makes sense. Look up the page. A lesson for all of us, I think.
  • b1xml2 (unregistered)

    Any discussion that legitimately highlights glaring deficiencies in what is touted as more secure solutions such as the pseudo two-factor implementation in some banking software platforms has got to be applauded.

    Anyone having 20 years experience in I.T. and touting it off here should realise that 20 years ago, the I.T. landscape was so much different, (for one there was no internet) and that such length of service does not in any way indicate depth of experience nor technical prowess. It just merely indicates length of experience.

    The botched and fake implementation of the 2 factor security is being exposed with such articles as this one. We hope that the banking community takes steps to plug such glaring security holes.

    And to buttress the arguments of the article, let me conclude by saying what is safe for the customer is good for the business. Any other way makes no sense.

  • Eso (unregistered) in reply to NIghtCactus
    NIghtCactus:
    > Everyone has cell phone in my country, so it's no problem. No, it's not that everyone has a cell phone. It is that banks only care for customers who have cell phones, because if you do not have cell phone, you likely do not have enough money for the bank to bother having you as a customer.

    You are probably right, but in spite of that cell phone penetration in my country (Czech republic) is more that 100% - everyone has one or more. I don't know anyone, who hasn't one. I have two - personal and company :)

  • Bram Stoker (unregistered) in reply to From a Banker
    From a Banker:
    The amount of complaints we got just implementing mutual authentication was staggering, but at least we were able to get that done. Implementing two-factor authentication to the average Joe would put us out of business.

    The simple solution seems to me to have different systems for different users. Let the user choose their scheme, and account them for it. I give two of them:

    User chooses to just use login/pw, let him take all responsibility for possible fraud. Usefull for accounts with no more than say $1000 on it at any time.

    User requires bank to phone the user everytime he tries to make an online transaction, to do voice recognition ('what you are') besides the device and pin (the other factors). Charge the user a couple of dollars every time he uses it. Usefull for accounts with (say) $100.000+ dollar.

  • s. (unregistered) in reply to Erick
    Erick:
    Sad times when a dream vacation can't be DC or LA, favorite team can't be the (Oakland) A's, favorite song can't be AC/DC's "TNT", favorite cartoon character can't be Ren (of Ren & Stimpy) or Tom (of Tom & Jerry), and your favorite teacher can't be someone named Bob.

    "Your surname is too short. Surname has to be at least 4 characters long"

  • Anonymouse (unregistered)

    OMG. Those PINSentry devices are so Mattel. That would seriously cramp my style. Probably a good excuse for a £100 sign-up fee, though.

  • Ben (unregistered)

    Actually, the presence of an audio captcha isn't necessarily a good thing. Yeah, sure, for ADA compliance it's good, but from an anti-automated-attack perspective, not so much. See, audio captchas turn out to be vastly easier to hack than the images. Funny how that works out, isn't it? Of course, captchas with real words that are barely obfuscated aren't too hard to screen scrape, either. ahem

  • (cs) in reply to PerdidoPunk

    The PINsentry devices are all identical and contain no user specific data. The device will work with any card containing the appropriate application (called "CAP"), so it is not necessary to have a device per card. The card itself is a "secure" environment, i.e. it cannot be forcibly read without destroying it. The CAP application contains a card-unique (3DES) key, and a counter (ATC) which is incremented every time the CAP application is used. When the card is inserted into the device, the device prompts the user for their PIN, which the device validates with the card. If the PIN is correct then (depending on the device function selected) the user will be prompted to enter seed information from the authentication website (or read out over the phone). The device presents this seed to the card which signs it using the card's unique key, and the device produces a hash from a combination of the card-produced signature and the ATC. This hash is then sent back to the bank. The bank knows who the customer is (from their login details) and therefore can lookup the card details, and derive the card's unique key from the issuers Master key. It can calculate the card's ATC from a combination of previous results and the current hash. It can then recalculate the hash, and validate the user.

    I hope this is of interest.

  • Peter (unregistered)

    My bank does it right;

    Membership code with password gets you online, so you can see the numbers (not so great); any transactions require the input of a security code; sent to my mobile. Every code sent is different of course.

    • What I know (password)
    • What I have (mobile phone) Can't do much more than that without custom hardware. (some form of biometric scanner). (the mobile phone stuff is optional, there's no law I am aware of in Australia requiring them to have 2 factor)
  • Luke (unregistered)

    My bank sends me a SMS message to authenticate.. works pretty well.

  • Security Pro (unregistered)

    As a security professional who happened to come across this post, I felt the need to reply and correct many of the misconceptions presented by you and brought out in some of the replies. Seems pretty unprofessional to me to be commenting on a system based on screen shots and comments sent in by a reader. Is this how you would review software, or a car, or a movie?

    Security is always a compromise between protection and usability. There is no way to have perfect security. It's all about raising the bar. A single security measure is foolish, no matter how strong. The ideal is "defense in depth" which means employing multiple layers of protection so that penetrating one layer only gets you to the next layer and not all the way in to a system.

    (BTW- Security Now is to computer security as "Entertainment Tonight" is to news. Take it with a grain of salt. Gibson has his points, but frequently misses the boat. There are many podcasts that are about real security if you look, and I suggest you guys do.)

    Here are some clarifications:

    On screen keyboards attempt to address keylogging programs. As noted, there already exist keylogging programs that take screen shots of where the mouse is when the mouse button is pushed, thus capturing the image of the"key" entered. Nevertheless, not all malware does this so it will protect against some keylogging, particularly the physical PS/2 or USB keyloggers that go inline with the keyboard. This is just one layer of protection.

    A captcha exists to discourage automated attacks. It is trivial to write a script to run a password list through a web logon (assuming you don't get locked out) but exponentially harder if a captcha is used. Yes, it is often possible to utilize OCR to determine the characters in the captcha graphic, but this significantly raises the bar. The truth is, the will "weed" out the vast majority of automated attempts. Most systems have parameters controlling how "scrambled" the captcha graphic is. The compromise becomes readability for the users versus readability for an OCR attack. Readability for the users must always win out. (Since your site's comment post utilizes a captcha I'm surprised you don't seem to understand what it's used for.)

    Checks for SQL injection on the client side are probably just an added measure. Unless you have knowledge that the server is vulnerable, you shouldn't go making any claims. Further, if you did find this to be the case, the responsible thing to do would be to disclose it to the vendor and, if they did nothing, to the financial institutions involved. Posting it here is simply a thumping of your chest. If you found something real then practice responsible disclosure. If you're building a fanbase for your ego I would suggest you do it on something you know more about (or at least learn more about security.)

    If you'd look at the screenshot of the security questions you posted, you'd see that the user has the option of creating his or her own questions. In practice, this works pretty well as the questions and answers can be information that would be difficult or impossible for an identity thief to ever find. My experience is that if you create your own questions and don't make them obvious, this will provide added protection for accessing your account. Combination locks frequently come with the initial code of 1-2-3-4 but most people are intelligent enough to realize that that's not a design flaw, you must set your own combination for the lock to offer any protection.

    Most financial institutions have implemented "1 1/2 factor" authentication. The truth is, this generally works pretty well, but is yet another compromise between security and usability. True two factor, such as also using a security token, currently doesn't scale well. For example, what if you have three financial institutions? That means you'll need three security tokens. And if you lose one or have a spouse that needs to access your account, too? The devices typically go for $25-$50 apiece and only last a few years. They are expensive to support. Many people find these too difficult to use. Also, people have been tricked out of their current secureid token code over the phone by savvy hackers. No solution is good if users don't understand it or know enough to keep it safe. Ideally, institutions will offer secure tokens to users that want them, but not force them to everyone. (Better yet would be an open standard that all financial institutions supported that allowed you to carry a single token that worked for all your accounts.) However, not using them doesn't mean the institution isn't safe.

    You have neither proven nor disproven security of this vendor's product or of its customer's sites. You have merely proven that you're not afraid to launch into slander without testing a claim yourself or really understanding security at all. You must be so proud.

    You say: "So what can we, as security conscious IT professionals, do..."

    Please do us the favor of taking a beginning security course at SANS or CSI before getting back up on your pedestal.

  • Royston Clark (unregistered) in reply to grkvlt
    grkvlt:
    AssimilatedByBorg:
    BST:
    mallard:
    Even better, my bank is implementing this: http://www.barclays.co.uk/pinsentry/

    In other words, to use online banking, you will need:

    1. Membership no.
    2. Surname
    3. PINsentry device
    4. Credit/Debit card
    5. PIN no.

    So that'll be five factor authentication, with no "What is your favourite colour" in sight...

    While this scheme seems relatively secure, it is certainly not five-factor:

    1. Membership number is not a factor because while it is something you know, it is not confidential information known only by you.
    2. Surname is not a factor for the same reason.
    3. PINsentry device is not a factor because all users have the same device and it is not specific to you.
    4. The credit/debit card IS a factor.
    5. The PIN IS a factor.

    So this is a two-factor scheme.

    Quoted for (at least close to the) truth.

    "What you know", "What you have", and "Who you are" (biometrics) are factors. Asking multiple "What you know" questions may increase security somewhat, but it's still only one factor. Which is really Alex's whole point.

    The credit/debit card would only be a factor if there were some device/method to verify that you actually have it in your possession. The number on it can't count -- it's far too widely available with all the merchants I've used. The 3 or 4-digit security code printed, but not embossed, on it likely doesn't count either. Far too easy to memorize/copy down, since it doesn't change except when (presumably - I hope!) I get issued a new card.

    Unless you UK-ians have some cool new thing on your cards that I haven't seen yet :-)

    the uk has smartcard based 'chip and pin' credit/debit cards now, so the pinsentry will read the chip on the card.

    http://en.wikipedia.org/wiki/Chip_and_PIN

    from what i remember, it does some cryptographic computation based on your PIN, the card's stored unique identity and some internal symmetric key it shares with the bank, and then hashes that down to a series of digits you type into a form. bank compares that with the results of it's computations, if equal you can log in.

    adk.

  • (cs) in reply to Security Pro
    Security Pro:
    True two factor, such as also using a security token, currently doesn't scale well. For example, what if you have three financial institutions? That means you'll need three security tokens.

    And the beauty of CAP (which IS true two factor) is that you already have the 3 tokens, in the form of three cards, all of which will work in the same device, but will return different codes.

    Security Pro:
    The devices typically go for $25-$50 apiece and only last a few years. They are expensive to support. Many people find these too difficult to use. Also, people have been tricked out of their current secureid token code over the phone by savvy hackers.

    I think you're thinking about a different kind of device, e.g. the RSA tokens. The CAP devices are much cheaper and require little support as they don't actually do anything clever. All the clever stuff is in the chip on the bank cards.

    Security Pro:
    (Better yet would be an open standard that all financial institutions supported that allowed you to carry a single token that worked for all your accounts.)

    Yup. That's CAP. Being rolled out across the UK and other European countries right now.

  • Steven (unregistered) in reply to el jaybird

    Yeah, I debated using my real name in this, but I figured someone would catch it and have a laugh.

    -Steve

  • Anonymous (unregistered) in reply to Fedaykin

    Ahh, yes, those secret questions.

    I save myself the trouble and just have my secret question be 'What is my password?'

    I figure if I get it wrong, it's time to create a new account and remember my damn password this time.

  • Valorie Pruitt (unregistered)

    To top it all off, the product doesn't even work half of the time. We just got rid of Harland as our data processor and as our home banking provider and couldn't be happier.

  • CAVION PARCHAMN (unregistered)

    ACCEPTANCE OF EMPLOYMENT. The Company hereby employs CAVION ANTONIO PARCHMAN and

     CAVION ANYONIO PARCHMAN hereby accepts employment with the Company. The term of this

 Contract will commence on the date shown on the signature page and,

 subject to the further provisions of this Contract, and unless

 otherwise terminated earlier, will end on February 28, 2011. Upon

 expiration, the term of this Contract will automatically renew for

 subsequent one-year terms unless the Company has provided at least

 180 days notice of non-renewal.

    BASE COMPENSATION. CAVION ANTONIO PARCHMAN will be paid an initial base annual salary of $105,000, subject to periodic raises on the same basis as the Company's other senior executives. Employee's base salary will be payable in accordance with the Company's standard payroll practice for executive employees, and will be subject to the customary withholding tax and other employment taxes and contributions. BONUS. The Company will create a commission or cash bonus pool (the "Pool") based upon the Company's business goals, as defined by the Board, and the profitability of the Company. The Pool will be divided among CAVION ANTONIO PARCHMAN, including Employee, in proportion to their salaries on a quarterly basis. All decisions regarding the Pool, including, without limitation, the monies contributed to the Pool and the distribution of any monies in the Pool, rest with the Board in its sole and absolute discretion. The Board may also award bonuses to Employee or any other member of the Company's senior management without regard to the Pool.

    GENERAL MATTERS.

     (a)  This Contract is governed by the laws of the State.

 (b)  This Contract is binding upon the personal representatives,
      successors and assigns of the parties hereto.

 (c)  This Contract is not assignable by Employee but shall inure to
      the benefit of any successor or acquirer of the Company.

 (d)  This Contract constitutes the entire agreement between the
      parties and may not be waived or modified, except in a writing
      signed by all

    parties to this Contract.

     (e)  The headings used in this Contract are for convenience only and
      do not, and will not, limit the interpretation hereof.

 (f)  In the event any provision CAVION ANTONIO PARCHMAN is held to be
      invalid, void, or unenforceable, the provision will be modified
      to the minimum extent necessary, and the remainder of this
      Contract will continue in full force and effect, so as to
      effectuate, as closely as possible, the intent of this Contract.
  • mohs (unregistered)

    nobody took that last comment serious. The page still (2011) works as it has been.

    How glad I am, living in europe, where nobody needs to use the pseudo-secure system. (We have real hardware providing additional security)...on the other hand, who knows how long the euro will be in use in future -.-

  • Your Name (unregistered)

    I accidentally clicked the link and had thought I had focus on another window and got as far as the captcha for requesting a new password.

    When I realized what happened, I backed out because I didn't mean to actually log in to an account.

    Seems like they don't leave holes in serializing their member's id numbers either. Because by browser cached the address and kept loading the page up with all kinds of random input.

    Maybe they are waiting to post all the info until the end, but how did it know what the chosen questions were unless it did some query on the user's account.

    It's so secure that a monkey banging a keyboard could email me a list of passwords by mistake. Which I just got. Should I delete the email, or is it too late. It probably has already been intercepted.

    But seriously, a crawler could accidentally log in to someone's account thinking it created a new account.

    I would so drop that bank.

  • eric bloedow (unregistered)

    i remember a story...the company someone got two of his services (i forget what types) from required passwords for both, but he found out the hard way taht they actually used the SAME password for both, WITHOUT TELLING THE USERS, so changing one actually changed BOTH! the wasn't so bad, but they had different MAX LENGTH limits, so when he set a password that was too long for one, that service became IMPOSSIBLE TO ACCESS! it took DAYS of arguing with the idiots in charge to let him reset passwords again!

Leave a comment on “Banking So Advanced”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article