Talk:Common Access Card

Deleted "Privacy" section

I deleted this section from the article:

Congressional law prohibits eavesdropping on the content of employees computer work, as per federal wiretapping laws. There must be a clear reason to do so, and that must be communicated to a judge, who would issue a warrant, before the contents of anyone's computer can be reviewed. Exceptions include casual observation by system administrators who're working on the computs for normal reasons. Any violations should be immediately reported to the individual's superior. The issue with the CAC is that it opens wide the door with respect to undetectible screening of the data stream. There are now ways that the system administrators can illegally monitor your Internet surfing and tie that surfing, undeniably, to you, in violation of Congressional law.

In addition, cards issued to service members are printed with both the member's name and social security number. Theft or loss of the member's ID card therefore gives others access to two key pieces of information needed for identity theft.

The bit about "Congressional law" (whatever that is) has nothing to do with CACs. The statement that the card is printed with the holder's Social Security Number is simply untrue. A CAC creates no more vulnerability to identity theft than any other formal identification card, such as the standard military ID used in the United States. ➥the Epopt 14:49, 1 September 2006 (UTC)

I just looked at my CAC and there it is, my social security number, printed on the back, just above the barcode. The previous military ID card had the SSN printed on it, as well. As for Congressional law, who do you think mandated (via Congressional Law) the CAC for use by all members and employees of the Department of Defense? Furthermore, Congressional Law also governs the privacy and wiretap laws we have in the US. Please provide better reasons for the deletion, or I will revert it in the near future. Mugaliens 13:21, 2 September 2006 (UTC)

Above the barcode on mine is a black-and-white version of my picture. Above that is the magnetic strip, and above that is an alphanumeric string grouped into four-character "words." No SSN anywhere. ➥the Epopt 23:33, 2 September 2006 (UTC)

I have the same, but my SSN appears right above the barcode. My card was issued in 2003. Perhaps yours was issued at a later date, after some of the privacy concerns were heard? Mugaliens 09:09, 3 September 2006 (UTC)

Also, are you a DoD employee, contractor, or military? That might make a difference. Mugaliens 09:10, 3 September 2006 (UTC)

Addendum: According to the US Navy's CAC Fact Sheet (pics at the bottom of the pdf file), all issuees except contractors get their SSN stamped on the card. Mugaliens 09:45, 3 September 2006 (UTC)

The barcode contains different information which includes SSN, Name, Gender, Paygrades etc... The reason why you wouldn't not have a SSN is because you are a contractor. All active military service members will be required to have a CAC card which incldues Active Reserve and National Guard from all branches. Metrofx 29 January 2007 (UTC)

I agree with the deletion of this section. What has been overlooked is that CACs are primarily used to access government systems. There should be neither private mail nor private files on a US Federal Government system. To quote US DoD Instruction 8500.2, control ECWM1: 'All users are warned that they are entering a Government information system, and are provided with appropriate privacy and security notices to include statements informing them that they are subject to monitoring, recording and auditing." The statements about whether SSN and other personal information should be on the card seems to come from a distinct point of view, and does not appear to be neutralTelmarg 14:01, 28 February 2007 (UTC)

I disagree with the deletion of the above. Perhaps rewording is warranted. The section is discussing "Objections" and therefore its understood to have a POV. However, it is a fact that Date of Birth & Social Security Numbers are on the majority of CACs, making identity theft easier in the case of loss or theft. This is a concern based on fact & quite valid. Dymaxion (talk) 20:34, 15 April 2008 (UTC)

FWIW, McGuire AAFES had a notice up today indicating that SSNs will not be printed to any (contractor or otherwise) CAC cards after Sept 2009. No further verification of this, but thought I'd mention it. Tvh2k (talk) 03:56, 17 June 2009 (UTC)

Found a source: [1]. By end of CY'08 all dependents SSNs were removed from DD Forms 1173 and 1173-1. By end of CY'09 all visible SSNs will be off CAC cards, except last 4 digits on Geneva ID cards (green and CAC cards), which remain indefinitely. Barcodes will also still have "encoded" (not encrypted) SSNs. By end of CY'12 all SSNs will be gone, visibly and encoded in barcodes, except last 4 digits for Geneva IDs. Tvh2k (talk) 04:11, 17 June 2009 (UTC)

Deleted "Security" section

I deleted this section from the article after realizing I was filling it up with {{Fact}} tags:

The idea that the CAC significantly increases security is severely flawed. Under the username/password approach, hacking a person's password required either an over-the-shoulder approach, intercepting the user's hashed password and using a tool such as L0phtCrack, or the use of a keyboard recorder, a small device which sits between the keyboard and the USB or PS2 port. These approaches required physical access to the LAN. With the CAC approach, hacking a person's password became only slightly more complicated. It now requires both a keyboard recorder as well as a tap on the digital stream of information between the computer and the network. The keyboard recorder will record the PIN, which is strongly encrypted over the network, but not encrypted between the keyboard and the computer, while the digital stream tap will record the CAC's unique ID (usually a multidigit number), which is not encrypted.

It contains numerous inaccurate statements, and correcting them is not within the scope of this article. For example, there are many more ways to crack a username/password login than are listed, none of which cannot be used on a CAC login. Also, the statement that the PIN is "not encrypted between the keyboard and the computer" is not true in high-security situations. ➥the Epopt 14:55, 1 September 2006 (UTC)

CAC readers do not encrypt the PIN. That's handled at the software level as part of the Windows logon routine. In "high security situations" such as when logging on to the SIPRnet, the same CAC readers are used that exist on the NIPRnet. The additional security is provided by controlling physical access to the machine. You have not made a single correct statement in your comments above. If references are needed, I'll fill it to overflowing, then revert the article, unless can can provide unequivocable justifications to back up your comments. Mugaliens 13:25, 2 September 2006 (UTC)

Please do exactly that -- provide sources for the statements you want to include. If you word them in the form "SOURCE X believes that CACs have SSNs printed on them," I won't delete them. ➥the Epopt 23:30, 2 September 2006 (UTC)

You bet. Mugaliens 09:10, 3 September 2006 (UTC)

It appears someone added all the inaccurate information back in. The part about a "digital stream tap" sounds like a man-in-the-middle attack, which assumes the data can simply be replayed. If you look at the Microsoft article describing the smart Card logon process, you will see that a time-stamped (per Kerberos) challenge is sent to the smart card in order to decrypt the logon session key (Microsoft article). Without possession of the private key, it would be impossible to decrypt the data. The information posted in this article says nothing about extracting the user's private key from the smart card, which is a significantly more difficult process, and would require physical access to the card--I don't even know if it is possible. 131.28.31.217 23:55, 11 December 2006 (UTC)

I added some citation requests to the section. The text currently reads as nonsensical conjecture. If someone has demonstrated such a vulnerability, whereby obtaining the PIN and "tapping the digital stream" results in a compromised private certificate, or somehow fools the KDC into trusting a forged certificate, then they need to cite some references. 131.28.31.217 23:25, 13 December 2006 (UTC)

While "all cryptographic operations are performed on the KDC," as per the article, the PIN entered by the user travels cleartext between the keyboard and the computer. Any keystroke recorder inserted between the keyboard and the computer can intercept the PIN. Since many users leave their CACs in the computer, it's a simple matter to remove their CAC, walk over to another computer, extract the PIN from the recorder, and log in with another user's credentials. - Mugs 08:08, 4 January 2007 (UTC)

I deleted this section, as it contained logical flaws that rendered it invalid. The main point of the section seems to be that the PIN could be captured, and this is equivalent to capturing a password. I find this to be nonconvincing, as there are distinct differences in the two situations. While the PIN and password can both be captured remotely (remote keyloggers, for instance), the password can also be used remotely to attack the system. The PIN cannot, as it is of value only when the CAC is present. In addition, passwords are typically stored (encrypted) on the systems, leaving them potentially vulnerable to brute force, dictionary, or rainbow attacks. The PIN is not stored in the system. The bottom line is that the password is a single-factor authentication scheme, and one easily compromised at that. The CAC is a two-factor authentication scheme, with the hardware factor requiring possession of the CAC itself. See US National INstitute of Science and Technology Special Publication 800-63 Version 1.0.2, pp vii and others. I quote:

"Level 3- Level 3 provides multi-factor remote network authentication. At this level, identity proofing procedures require verification of identifying materials and information. Level 3 authentication is based on proof of possession of a key or a one-time password through a cryptographic protocol. Level 3 authentication requires cryptographic strength mechanisms that protect the primary authentication token (secret key, private key or one-time password) against compromise by the protocol threats including: eavesdropper, replay, on-line guessing, verifier impersonation and man-in-the-middle attacks. A minimum of two authentication factors is required. Three kinds of tokens may be used: “soft” cryptographic tokens, “hard” cryptographic tokens and “one-time password” device tokens. Authentication requires that the claimant prove through a secure authentication protocol that he or she controls the token, and must first unlock the token with a password or biometric, or must also use a password in a secure authentication protocol, to establish two factor authentication. " Other references abound.Telmarg 14:10, 28 February 2007 (UTC)

Objections Section Restored

Complete with a plethora of references, a few quotes, embedded links to additional info on Wiki, and other citations. If you feel any portion is still lacking references, please let me know and I'll add them within a few days. Thanks! Mugaliens 12:46, 3 September 2006 (UTC)

I think it's time to remove the "factual etc. disputed" page, unless anyone can provide clear, unrefutable evidence that counters the information contained in the many links I provided. Thank you. Mugaliens 20:59, 24 September 2006 (UTC)

Since no further comments or objections have been raised for nearly two months since I provided the links and references, I've removed the Disputed sign. Mugaliens 14:20, 31 October 2006 (UTC)

Leaving CAC in the computer

Many users running around the workplace habitually leave their CACs in the reader when they step away from their computers for a few moments. I know this for a fact as I've seen it happen many times. Anyone who works in or with the DoD can tell you the same thing. Mugaliens 14:26, 31 October 2006 (UTC)

Untrue. I work with the DoD and can't tell you that. I have removed your original research. ➥the Epopt 14:38, 31 October 2006 (UTC)

Your office must be much more disiplined than ones I've visisted. As networks have started to require CAC use for logging in, I've seen lots of cards sticking out of keyboards. Still, without a published reference, I agree that it should not be in the article. Somewhere out there, a security evaluation must have been done. Any evaulation would likely list leaving the card behind as a risk factor. --StuffOfInterest 15:11, 31 October 2006 (UTC)

Thanks for the second opinion. You're correct - such an evaluation was done in 2000, and so many people left their CACs in their computers that the CAC system settings were changed to provide an automatic workstation lockout after several minutes of inactivity, regardless of whether the CAC is in or not. - Mugs 07:56, 4 January 2007 (UTC)

It is true and I seen it happen all the time. I work in an office and administer 140 Army computers. People with all difference ranks leave their CAC cards in their readers all the time and walk away.- Metrofx 29 January 2007 (UTC)

True as heck. I left mine in once and got in some bad trouble when someone took the opportunity to send some incriminating emails under my name.

If you left your CAC in a PC and left the base, it is VERY difficult to get back on-base, since the CAC is also used as visual identification at the gate. Speaking of showing your CAC at the gate, one time I entered a naval base with mine. The MP was wearing a belt around his waste, and on front it was a magnetic strip reader. He would take your CAC and swipe it on the reader. I only saw this done that one time, so I assume it was an experiment. It would be interesting to know if others experienced this, and if the DoD will eventually implement this method at all gates. Groink (talk) 00:50, 30 October 2008 (UTC)

I work in the Signal Corps and most every one removes their cards. Every S1 section I've seen has multiple CACs left in place while the S2 are paranoid like us and remove theirs. It's all about the leadership and their emphasis and different aspects of security protocols. — Preceding unsigned comment added by 71.68.24.52 (talk) 14:48, 16 September 2011 (UTC)

Geneva Conventions

The CAC card has been called a Geneva Convention ID card, but I don't see such a statement on this page. If true, what part of the Geneva Conventions apply? --Boblord 18:02, 11 November 2006 (UTC)

I'm not an expert on the Conventions, but my CAC says right on it, "Geneva Conventions Identification Card". The same was true of the previous military ID.Roachmeister 00:27, 1 December 2006 (UTC)

Answer: Convention (III) relative to the Treatment of Prisoners of War. Geneva, 12 August 1949, Article 4.A.(4): "Persons who accompany the armed forces without actually being members thereof, such as civilian members of military aircraft crews, war correspondents, supply contractors, members of labour units or of services responsible for the welfare of the armed forces, provided that they have received authorization, from the armed forces which they accompany, who shall provide them for that purpose with an identity card similar to the annexed model." Depending on one's rank or duties, they will fall into one of five Geneva Conventions categories. - Mugs 09:20, 4 January 2007 (UTC)

NPOV - "A better approach"

I added the POV-section tag, primarily for the part about "A better approach". It may or may not be true, but the way it is worded seems like so much advertisment for SANS.Roachmeister 00:24, 1 December 2006 (UTC)

Actually, not an advertisement at all - merely industry-standard security practices. Regardless, Epopt deleted it anyway, wrongly claiming "that has nothing to do with CACs and so is irrelevant to this article." Current CAC security is flawed, and industry-standard practices exist which can fix the flaws - that's highly relevant to this article. - Mugs 07:51, 4 January 2007 (UTC)

Text Removed

The following text was removed: "though that legislation is irrelevant to the work of military personnel." Reason: Congressional law applies equally to the military as it does to civilians unless specifically stated otherwise. No military member, including Security Forces or OSI personnel, or civilian authorities, may search the personal files or e-mails of another military member without a court order. Casual oberservance of a person's files during the routine maintenance of the computer by an authorized service technician is allowed. - Mugs 07:52, 4 January 2007 (UTC)

As A RAPIDS user, I believe some of the information on this page to be out of date, incomplete, incorrect, or down right lies. I will offer a complete review of the article and offer my suggestions on how it can be improved. I think in response to the claim that the article is biased, I believe the article as it is presented right now although incorrect is neutral. Bruce R. Jones 03:04, 13 March 2007 (UTC)

RFID

In the section that states, "Future plans include the ability to store additional information the incorporation of RFID chips or other contactless technology to allow seamless access to DoD facilities.", I believe cretain elements of that statement are incorrect. First, regarding the ability to store additional information, the card already has the ability to store information; however, DMDC has stated on numerous occasions that the CAC should not be considered a data carrier and instead should be considered an authentication token to backend databases. Next, the incorporation of RFID chips should be updated to reflect the Department's decision to pursue 14443 contactless technology. This is detailed on the www.cac.mil website. My feeling is that unless such forward-looking statements come from the horse's mouth (a.k.a., DMDC), then they should be considered conjecture.

Common Problems

"The CAC card is far from perfect due to design flaws. The microchip can be damaged easily from foriegn objects scratches such as sand. Looking at the card at a more technical level, the cards have certificate issues where users can't log on even through their computers are setup correctly. Also different brands of cards have posed an issue with different systems."

I take exception to the statement of "design flaws" as well aa several other statements in this section. It is perfectly reasonable to say that the CAC is far from perfect, but to categorically classify this as attributable to design flaws, is not accurate. I would recommend deleting this statement. Also. the microchip can be damaged, but to say that it can be easily damaged without something to bolster that claim, is not defensible. The microchips are put through rigorous tests by the card manufacturers to ensure they can hold up in adverse conditions (e.g., scratch, corrosion, etc.). Also, DMDC produces card failure reports, and failures due to chip damage are not a significant number. Next, the section that starts "looking at the card at a more technical level", makes some anecdotal statements without any reliable source to bolster the claim. These types of issues most likely have less to do with the card and more to do with the individual network (e.g., middleware deployment, ActiveDirectory forest, etc.). Anyway, it is hardly a rigorous technical examination. I recommend amending or deleting this entire section based on the disputes outlined above. —The preceding unsigned comment was added by Jmac7997 (talk • contribs) 18:18, 19 March 2007 (UTC).

Regarding the problem with the CAC not logging a person onto a PC, this is more of a problem with the PC build, and the CAC itself. The CAC standing by itself works as advertised. The authentication problems people experience with the use of the CAC is a combination of or more things, including the PC's build, NMCI's active directory (Navy/Marines), the certificate authority management within the DoD, among other things. Regarding upgrading, again it isn't the CAC itself that is at fault, but rather it is poor planning by the administrators when switching to a different type of card used for CACs but not upgrade the card readers and/or the middleware. Groink (talk) 01:53, 30 October 2008 (UTC)

I definitely agree. This is a common problem in any enterprise when issuing equipment out to field personnel. There are many ways to mitigate this issue. Failure to mitigate is not an issue with a smart card, it's an issue of policy. I work for the federal government, we make people pick up equipment, no matter the distance. Or use temporary local accounts (without classified data) — Preceding unsigned comment added by 72.83.221.99 (talk) 02:19, 18 May 2016 (UTC)

Scalability

Doesn't the scalability section support the use of a CAC, instead of where it falls in this article (under objections)?167.176.6.27 02:53, 9 November 2007 (UTC)

TMA

Too many acronyms. "...driven by one's POV"? TDY? —Preceding unsigned comment added by 71.205.58.127 (talk) 05:26, 1 January 2008 (UTC)

Personally Identifiable Information (PII) on CAC?

Can anyone tell me if there is, definitively, PII on a user's CAC card and post links? I know that on active duty, your CAC displays your Social Security number, but I have a contractor ID and I cannot find any information besides name. Not even DOB is on there! I ask because we are trying to implement a system that would sign out an item to a person using their CAC as verification. The bar code on the back, when scanned, seems to generate a user-specific yet arbitrary CAC identification number. I can detect no pattern in these numbers. I do understand that the number is unique to each CAC. Thanks Kill. (talk) 21:37, 7 April 2009 (UTC)

I believe that the information about DOB, SSN, etc. is embedded in the storage chip, and not through something that can be seen just by looking at the card. Check out http://www.chips.navy.mil/archives/01_summer/cac.htm . Groink (talk) 22:16, 7 April 2009 (UTC)

I believe that information is actually associated with a database, retained by RAPIDS. The information actually stored on the CAC comes from DEERS.

According to the site: "The Social Security number (SSN) appears only on the Geneva Conventions CACs and those cards used to facilitate medical benefits or privileges. The SSN does not appear on Civilian and Contractor identification cards. In order to verify a claimed identity, the SSN is securely stored on the chip of the card. Access to controlled systems and applications is required to interpret the data and may only be viewed after entering a PIN known only to the CAC holder. "FAQ --Bynaural (talk) 04:47, 22 June 2009 (UTC)

It is true that the data is stored originally in a database. However it is just a general db for the DoD. Access to the database is very limited, such as the time the CAC is created. When the CAC is read on a stand-alone system, with the correct key, the DOB and such can be extracted from the card, and without the database. Think about it: in times of war, you can't always have access to the database. The CAC can be used like dog tags out in the field. groink 05:44, 22 June 2009 (UTC)

Suggestion

You should include that the PIN is, typically, a 4-digit number.

You should include how the CAC Card contains both the HTTP and the S/MIME Certificate(s). The S/MIME certificates are published to the GAL; whereas, the HTTP certificates are kept in the machine store for mainframe/web access.

The user(s) can send encrypted mail to anyone within the organization, as long as the target user's Digital Signature is listed (and valid) within the GAL. A minor note is that they can send encrypted mail to individuals outside of the organization, but first a S/MIME exchange must occur. (Users must send signed emails to each other; then they can encrypt messages.)

The "certs" are updated with the re-issue of a new CAC; the life-cycle of the CAC, of course, is organization specific. The new CAC will not be able to unencrypt previous emails and is a problem for some organizations, as publishing the certificate to the GAL replaces the old certificate - permanently. (Often the case, with a lost CAC.)

The certificate, itself, generally takes anywhere from 12-24 hours to replicate throughout the entire domain (GAL and client address books); but users often have to poll the GAL for new certificate of target users - as their cache does not update with the new certificate.

When users "pull their CAC", it locks the system. This is a requirement for most sensitive and or secret/top-secret sites, such as DoD's DFAS.

Also, you could include that some of the issue with logging in are due to Timbuktu or Credant (http://www.credant.com), among other software packages - known to cause conflicts with CACs.--Bynaural (talk) 04:25, 22 June 2009 (UTC)

Many of your points are specific to how NMCI uses the CAC. Other armed force branches may not be the same. For example, the GAL under AAFESS is not structured the same as NMCI. And, the pin number isn't only 4-digits; mine is seven digits. groink 04:33, 22 June 2009 (UTC)

Actually, my points are specific to DoD/DFAS.

If your division/organization/department doesn't use the CAC in the aforementioned way, it does not mean that the information should be negated. The article is about the use and implementation of the Common Access Card and it should not with-hold information, based on the fact that a particular department does not implement a particular use/function of the CAC.--Bynaural (talk) 05:46, 22 June 2009 (UTC)

What I'm saying here has nothing to do with use/non-use of the CAC. I'm saying that the CAC is used in different ways by different armed forces. For example, NMCI controls the active directory and the MS Exchange GAL for the Navy and Marines, and AAFESS does the same thing for the Army and Air Force. When you mentioned the about cert updates, it depends on how fast replication within AD is, and NMCI updates the certs in their GAL much faster than 12 hours (and the high side might take just minutes.) The refresh between clients is more of a Microsoft Outlook/Exchange issue than a CAC issue. And, as I mentioned earlier, the PIN requirement is much longer than four digits. When I had to pick a PIN number for myself, I think the minimum was six digits, and my CAC was created at an Air Force base. In short, DFAS has their requirements, but the other branches and security levels can apply additional applications and rules, such as gold vs platinum disk certification, high vs low, etc. as they see fit. When you apply your suggestions, you must make sure that on each point, you clarify the department that enforces the point. groink 06:42, 22 June 2009 (UTC)

But what you're failing to recognize, is that if "the CAC is used in different ways by different armed forces" it does not equivocate that mentioning that some departments store the S/MIME within the card's memory should not be mentioned - at all.

Also, one could mention that the CAC (for DFAS) contains 3 certificates. One is the DOD CA-19/20 and the remaining two are DOD Email CA-19/20 certificates. So, in DFAS the CAC contains 3 certificates - not just the PKI for HTTPS/SSL.

I'll admit that the limitation of the 4-digit PIN is a DFAS-dependent rule, but I can't honestly, without a doubt, say that no other organization uses the CAC to store the S/MIME.

So, as it stands, I don't know if there is a limitation on the possible number of certificates, that can be stored on the CAC. Does that mean that even mentioning that S/MIME can be stored on it should be with-held, just because you're department does not? That seems illogical to me.--Bynaural (talk) 15:46, 22 June 2009 (UTC)

Why are you reading into this that I want to exclude information? I've read my comments up and down, and I don't see myself saying this. All I'm saying simply is to cite the proper authority for each point:

Apply for CAC through your DOIM - through JPAS

PKI certificates (what you're calling S/MIME) standards - DoD

PIN number length - depends

Speed of replication of certs in GAL - depends

Syncing between client PCs - depends and unrelated to CAC, as even exempt people (ones without CAC who still log in with username/password) have "soft" certs in the GAL.

That's all there is to it! If you took your training on CAC and PKI CERTs like everyone within the DoD and armed forces is required to do, you should've understood this already. groink 23:08, 22 June 2009 (UTC)

So, let me delve deeper:

What you're calling PKI is used for HTTPS/SSL Handshakes. What I'm calling S/MIME is used for Digital Email Signing and Cryptography. While they both use the same premise (cryptography), their use is two different environments: One is HTTP handshake (a browser) and the other is used in SMTP relay.

The Basic access authentication runs in TLS/SSL at the application level, whereas the S/MIME runs in SMTP of the application layer. The only inclusion is of the basic access authentication and no mention of S/MIME; while they run on the same layer of the OSI Model, their invokes are different.

To clarify, you can not use a DOD Email certificate to look at the ePortal site; nor can you use the PKI/HTTPS certificate to encrypt email.

See the NOTE on this PDF, at step 6: WAWF Renewal

Using this logic, why would DoD place 3 certificates on a CAC (if they can handle both HTTPS/SSL and SMTP), when one PKI certificate would do? --Bynaural (talk) 17:51, 23 June 2009 (UTC)

Here is anFAQfor the Navy portal - if that helps. --Bynaural (talk) 08:08, 24 June 2009 (UTC)

Also, there was problem with the CRL and it was replaced with OCSP. Be sure to check out the Browser Support - as well. Further reading on this issue can be found here.

(Though, that may deserve to fall under "CRL". I'm not sure, as I can't say that each Department's CA uses CRL or OCSP for the basic browser authentication.)--Bynaural (talk) 08:30, 24 June 2009 (UTC)

Here Is the CAC PKI email Quick Reference Guide from USMC.

Here is a CAC walk-through for the Army; mentioning: "Be aware you may have more then one certificate displayed (e.g. an Email certificate for Encryption or Signature). If you select the wrong certificate, and the system does not allow you to Sign In, you must Close your existing browser and Open a new one to be able to reselect the appropriate certificate."

Hereis a walkthrough from DMDC (which falls under OSD).

Here is a walk-through from the Army National Guard, for CAC Registration in GKO.

Here is a CAC Help Section from DTIC.

Here is CAC help from Military Community and Family Policy. Note the section in red.

Have I cited enough proper authorities?--Bynaural (talk) 09:40, 24 June 2009 (UTC)

One could also cite that users in TEMPEST (See NSTISSAM also) certified sites have no cause for concern about PIN security. (But this could be ignored, since the "Privacy" section was removed.) --Bynaural (talk) 09:56, 24 June 2009 (UTC)

I am a contracted technician who supports DFAS. There's a lot to comment on, but I'll pick one thing. Concerning encrypted email and a lost CAC, there's a DOD published application called Mailcrypt that can decrypt email. It can be downloaded from the DKO website. It can use the old certificates that are cached on the system. If those have been deleted there's a website that can often recover old certificates. I don't wish to publish it here because it may be a breach of security.Stillwaterising (talk) 19:22, 7 September 2009 (UTC)

I've always had to use 6 digits for Air Force PINs. --Krisirk (talk) 21:06, 13 July 2011 (UTC)

US Code

According to 18 United States Code Section 701, Part 1, Chapter 33: Whoever manufactures, sells, or possesses any badge, identification card, or other insignia, of the design prescribed by the head of any department or agency of the United States for use by any officer or employee thereof, or any colorable imitation thereof, or photographs, prints, or in any other manner makes or executes any engraving, photograph, print, or impression in the likeness of any such badge, identification card, or other insignia, or any colorable imitation thereof, except as authorized under regulations made pursuant to law, shall be fined under this title or imprisoned not more than six months, or both. This picture you have displayed of the Common Access Card is actually against this code and should be removed (even if it is just an example). http://uscode.house.gov/download/pls/18C33.txt Jason021388 (talk) 05:45, 22 April 2012 (UTC)

Seriously?!?!?! Watched a few NCIS episodes? Noticed that they show CAC cards that look even more real than what is on this Wikipedia page? I also took the image and found it on at least eight other web pages across the Internet. I also found hundreds of similar examples via Google. A sample of a CAC is even found on militarycac.com - a site that is NOT run by the government. I think you're reading into the regulation far too much. Groink (talk) 09:31, 22 April 2012 (UTC)

Yes seriously, it is actually against the law; as stated in the code. Jason021388 (talk) 20:06, 22 April 2012 (UTC)

Removed cost information

I removed the cost information from the article, despite the three citations. Two basic reasons why I did so. First, two of the three sources were from over ten years ago, so the cost information is dated. Although one of the three sources is dated 2012, the second reason I removed the information is that the 2012 source does not exactly explain the cost of the CAC. You have to define what "cost" really means in regards to the CAC. Although a family member can obtain a CAC for only $8, there is a cost to the government that is much, much more than $8. For starters, you have to consider the cost to JPAS. That involves background checks, regardless of the clearance level the person has (confidential, secret, top secret, etc.) Then, there is the cost of materials. The RFI technology alone in the card is quite expensive. And, the certificates on the card also has a cost. Matter of fact, CACs for family members do not contain encryption or digital signature certificates on the chip. And last, although a family member can obtain a CAC for just a few dollars, it is much more expensive for a soldier, government employee, contractor, etc. So, the next time someone wants to talk about the cost of the CAC, it must be broken down into its parts - and not just the up-front cost for the holder. Groink (talk) 04:07, 13 January 2013 (UTC)

Wow. So can't we just add the cost back in with your caveats? Are you going to apply that same standard to the entire article? There's a a bunch of facts with zero citations, why not delete them? Oaktreezulu (talk) 20:20, 13 January 2013 (UTC)

Then, based on your logic, you'd also rather post 10-year old information, as well as information that is 98-percent untrue. $8 for a CAC? Wrong! Groink (talk) 23:27, 13 January 2013 (UTC)

Other things you failed to point out on the last update... You assumed that the cost of the CAC at just one location is the same at the thousands of other locations. The point is that there is no consistency in pricing. My base's CO can charge whatever price he wants. Even if you justify the price, saying that the $8-12 is only at one location, the reader will still assume that the price will be similar across the nation and the world. As a fellow editor, I have a right to judge the quality and validity of the sources. You are basically applying WP:SYNTHESIS in your research, in that by putting these three articles together, you're coming to a conclusion that doesn't exist. You think there's a price per CAC when in fact there NO source out there that will tell you the price of a CAC for every base, every personnel, or even the idea that there is even a price to begin with. Groink (talk) 23:38, 13 January 2013 (UTC)

The only thing I will accept regarding pricing for a CAC is that the source is from a dot-mil or dot-gov, and that the source states completely and without synthesis that the price of a CAC around the world is an X amount. Groink (talk) 23:48, 13 January 2013 (UTC)

Well, we can just go round and round on this...How do you know anything is 98% untrue when you don't have anything to back up your statement? How do you know what the cost of entering someone in JPAS is or the cost of RFID tech in the card? You offer no data on this. In the amount of time we've spent talking about this, between the two of us we could have looked up several more sources. Thanks for wasting my time and not contributing. You win, your page, see ya. Oaktreezulu (talk) 00:42, 14 January 2013 (UTC)

I'll be happy to answer. I am in fact an ISSM, a CISSP, a technician certified by CNIC to operate CAC equipment, and a certified professional engineer employed as a civilian in the U.S. Army. I personally interface with JPAS, and handle personnel registrations on a daily basis for our command. I am a primary source, which disqualifies me from adding information to this article regarding CAC processing and procurement which is classified information. But, as a primary source, I can see and disqualify mis-information. Again, your methods of Wikipedia is wrong. You do not come up with a hypothsis, and then look for sources to justify your hypothesis, thinking your research turns it into fact. Much of the CAC article is written under the guidance of the information that can be found on the dot-mils and dot-govs. Those sources write this article. As you pointed out, some of the information is not cited. I'm working on this, as you probably have noticed. It isn't something I have one day to dedicate myself on, which is why I've left the citation notice at the top of the article as-is. Groink (talk) 01:03, 14 January 2013 (UTC)

You say you are primary source, yet we have no documentation of this either...Oaktreezulu (talk) 01:32, 14 January 2013 (UTC)

History and manufacturer

When were these first issued? Who developed the system? Who manufactures them? -- Beland (talk) 20:31, 6 March 2013 (UTC)

All of those points are confidential. What's in the article is what is available via public sources. Groink (talk) 05:23, 7 March 2013 (UTC)

Actually, not all of them are. The CAC was first issued by the DoD in October 2000. http://usmilitary.about.com/od/theorderlyroom/l/blsmartcards.htm 132.3.49.82 (talk) 19:15, 14 June 2013 (UTC)

About.com is not a credible site for issues regarding DoD issues. Better to find a DoD dot-mil site. Groink (talk) 23:22, 15 June 2013 (UTC)

I agree with the OP. There should be a "HISTORY" section. How were the old "ID cards" phased out? WHERE was the CAC first issued (as in city or military base or federal department, etc.)? Was there an overlap and transition period? WHEN were the old ID cards fully replaced? Starhistory22 (talk) 21:53, 29 July 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Common Access Card. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20140714201449/http://www.doncio.navy.mil/chips/ArticleDetails.aspx?ID=3381 to http://www.doncio.navy.mil/chips/ArticleDetails.aspx?ID=3381
• Added archive https://web.archive.org/web/20121126080942/http://directory.fedoraproject.org/wiki/CoolKey to http://directory.fedoraproject.org/wiki/CoolKey

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 10:03, 11 August 2017 (UTC)