Closed bluikko closed 7 years ago
Would you like one PUK key for all cards?
As for the retry counts, we discussed that in a previous round and settled on not introducing the complexity. But for sure, some could need it. We envisioned setting it in a general settings, and then on enrolls and pin resets to set this new retry count.
I just read the documentation again and I can live with reading the PUK from store file for the records. Is there a reason it cannot be viewed in application?
And one more stupid question. In some documentation it is said that the "set-ccc" operation must be done with yubico-piv-tool. Is this done by EnrollmentStation?
Most questions are not stupid :)
The reason it's not displayed is partly a usability thing and partly a security thing. For the usability, it may confuse users more than it gains (we haven't had a request for this before, as an example). Users may incorrectly believe they MUST save the PUK key (since you MUST save a PUK key for a SIM Card f.ex.), leading to extra unecessary tasks.
For the security side, we don't want users to bring secret values out of the protected environment. If we started showing the PUK key, the users would become aware of it and possibly begin writing them down and storing them elsewhere. The mere display of the value invokes thoughts and processes that can only reduce the security of the system.
Would you mind explaining why you need the PUK key? .. I'm very curious as to what process requires it :).
The ES does not run the Change Mode processes automatically. We had an idea about providing a Change Mode dialog and functionality, but it died a little. It turns out, that the Yubikey will present itself as three different types of devices with three different client libraries. You can Change Mode with any of the client libraries, but only if the Yubikey works with a specific Mode.
If you f.ex. came with a Yubikey that was set for only OTP mode, we need to run the OTP client library to discover the Yubikey, and then investigate and change the Mode of they key, only to require you to detach/re-attach the key and have it rediscovered by the OTP and PIV libraries.
We would effectively need to support all three libraries and have discovery routines in place regularily for all three client libraries for this one feature. We opted not to do this.
It was just a requirement to document the PUK per card. I can do it by reading from the file.
Regarding Change Mode, I definitely would not need it and did not know it is the same thing as the "set-ccc" functionality of the yubico-piv-tool. This was just confusion on my part and may be disregarded then.
Thank you for your time.
@ian-csis would you have anything against showing the PUK key?
I went ahead and prototyped it. I extended the cert display with a hidden field:
Clicking the Show link reveals the key:
Selecting a new enrolled key will hide the field again and show the Show link. So you explicitly have to click Show to reveal each key.
@bluikko we looked at the prototype I made and decided not to go with it for now. You have a work around that works for you, and in our opinion the PUK keys shouldn't be outside this system.
I'll close this for now - Write back if you have other questions. :)
We had the same problem.
The smart card are in China and the users has tried to changed the pin in the integrated pin change logon screen of windows 7 and blocked it. Because the hotfix kb2808693 was missing the gpo didn't work.
https://forum.yubico.com/viewtopic64dc.html?f=23&t=2495
This is way we had to change the pin without resending it.
yubico-piv-tool -k $ManagementKey -a unblock-pin -P $OldPuk -N $NewPin
We solved the problem by writing a powershell script to export the store in csv format .
$prgPath="C:\Program Files (x86)\Enrollment Station v0.3.5.0"
[Reflection.Assembly]::LoadFile("$prgPath\Newtonsoft.Json.dll")
$logDate = get-date -f yyyyMMddhhmm
$csvfile = "$($prgPath)\export-puk_$logDate.csv"
# list to export
$longlist = @()
# functions
function ConvertFrom-JObject($obj) {
if ($obj -is [Newtonsoft.Json.Linq.JArray]) {
$a = @()
foreach($entry in $obj.GetEnumerator()) {
$a += @(convertfrom-jobject $entry)
}
return $a
}
elseif ($obj -is [Newtonsoft.Json.Linq.JObject]) {
$h = [ordered]@{}
foreach($kvp in $obj.GetEnumerator()) {
$val = convertfrom-jobject $kvp.value
if ($kvp.value -is [Newtonsoft.Json.Linq.JArray]) { $val = @($val) }
$h += @{ "$($kvp.key)" = $val }
}
return $h
}
elseif ($obj -is [Newtonsoft.Json.Linq.JValue]) {
return $obj.Value
}
else {
return $obj
}
}
function ConvertFrom-JsonNewtonsoft([Parameter(Mandatory=$true,ValueFromPipeline=$true)]$string) {
$obj = [Newtonsoft.Json.JsonConvert]::DeserializeObject($string, [Newtonsoft.Json.Linq.JObject])
return ConvertFrom-JObject $obj
}
function ConvertTo-JsonNewtonsoft([Parameter(Mandatory=$true,ValueFromPipeline=$true)]$obj) {
return [Newtonsoft.Json.JsonConvert]::SerializeObject($obj, [Newtonsoft.Json.Formatting]::Indented)
}
# Main
$f = [System.IO.File]::ReadAllText("$($prgPath)\store.json")
$r=ConvertFrom-JsonNewtonsoft($f)
$list=$r.YubiKeys
for ($i=0;$i -lt $list.count;$i++)
{
$d = $list.DeviceSerial[$i]
$u = $list.username[$i]
$p = $list.PukKey[$i]
$m = $list.ManagementKey[$i]
$e = [Convert]::FromBase64String($m)
$f = [BitConverter]::ToString($e).Replace("-","")
$details = @{
serialnr = $d
username = $u
pukkey = $p
managekey = $f
}
$longlist += New-Object PSObject -Property $details
}
# export
$longlist | Export-Csv -Path $csvfile -NoTypeInformation -Encoding UTF8 -force
It would be very nice if a PUK code could be defined in CSIS settings. And the amount of PIN/PUK retries. Currently the CLI tool is needed to set these manually after programming the key with CSIS.