Definitions for CRL Reasons Is there any authoritative definition of the various reasons possible in a CRL file? Section 6.3.2(b) of RFC5280 lists a few:

unspecified
keyCompromise
cACompromise
affiliationChanged
superseded
cessationOfOperation
certificateHold
removeFromCRL
privilegeWithdrawn
aACompromise

I've looked and looked and can't find any reputable explanation of what these statuses each technically mean and I don't want to just assume their meaning given how the reason is phrased.

[Disclaimer: I work as a software developer on the software that powers one of the trusted public CAs, and many corporate internal PKIs]

tl;dr: to my knowledge, there are no formal guidelines for which revocation reason should be used in which situation, it's up to the discretion of the administrator or operator of each CA.

Typically, cert revocations are done by humans who have to choose one of those revocation reasons from a drop-down menu in the GUI. That means deciding which bucket a certain edge-case falls into may vary from one organization / CA to another, or may be entirely up to the discretion of the IT guy who is revoking the certificate for your ID badge, email access, web server, wtv.

In corporate Windows Active Directory CAs:

I found a really old article by Microsoft giving a bit of a text description of each reason -- search for "Revocation Reasons" on the page. (Microsoft built CA software as part of the Active Directory suite, so I assume this is accompanying documentation intended for Windows Domain Admins). See Appendix A at the bottom for the full list.

In the public internet TLS PKI

The CA/Browser Forum (CAB Forum) dictates policy for how publicly-trusted CAs and browsers need to behave with respect to certificates. Here is the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015. If you go to section 13.1.5 Reasons for Revoking a Subscriber Certificate (see Appendix B below), there is a list of situations in which the CA is required to revoke a certificate, but no mention of which reason code they're supposed to use.

tl;dr again: to my knowledge, there are no formal guidelines for which revocation reason should be used in which situation, it's up to the discretion of the administrator or operator of each CA.

Appendix A: some guidance from Microsoft on when to use each revocation reason:

  KeyCompromise. The token or disk location where the private key associated with the certificate has been compromised and is in the possession of an unauthorized individual. This can include the case where a laptop is stolen, or a smart card is lost.
  CACompromise. The token or disk location where the CA's private key is stored has been compromised and is in the possession of an unauthorized individual. When a CA's private key is revoked, this results in all certificates issued by the CA that are signed using the private key associated with the revoked certificate being considered revoked.
  AffiliationChanged. The user has terminated his or her relationship with the organization indicated in the Distinguished Name attribute of the certificate. This revocation code is typically used when an individual is terminated or has resigned from an organization. You do not have to revoke a certificate when a user changes departments, unless your security policy requires different certificate be issued by a departmental CA.
  Superseded. A replacement certificate has been issued to a user, and the reason does not fall under the previous reasons. This revocation reason is typically used when a smart card fails, the password for a token is forgotten by a user, or the user has changed their legal name.
  CessationOfOperation. If a CA is decommissioned, no longer to be used, the CA's certificate should be revoked with this reason code. Do not revoke the CA's certificate if the CA no longer issues new certificates, yet still publishes CRLs for the currently issued certificates.
  CertificateHold. A temporary revocation that indicates that a CA will not vouch for a certificate at a specific point in time. Once a certificate is revoked with a CertificateHold reason code, the certificate can then be revoked with another Reason Code, or unrevoked and returned to use.

  Note: While CertificateHold allows a certificate to be "unrevoked", it is not recommended to place a hold on a certificate, as it becomes difficult to determine if a certificate was valid for a specific time.
  RemoveFromCRL. If a certificate is revoked with the CertificateHold reason code, it is possible to "unrevoke" a certificate. The unrevoking process still lists the certificate in the CRL, but with the reason code set to RemoveFromCRL.

  Note: This is specific to the CertificateHold reason and is only used in DeltaCRLs.
  Unspecified. It is possible to revoke a certificate without providing a specific reason code. While it is possible to revoke a certificate with the Unspecified reason code, this is not recommended, as it does not provide an audit trail as to why a certificate is revoked.

Appendix B: 13.1.5 Reasons for Revoking a Subscriber Certificate from CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015:

  CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015:

  The Subscriber requests in writing that the CA revoke the Certificate;
  The  Subscriber  notifies  the  CA  that  the  original  certificate  request  was  not  authorized  and  does  not retroactively grant authorization;
  The  CA  obtains  evidence  that  the  Subscriber’s  Private  Key  corresponding  to  the  Public  Key  in  the Certificate  suffered  a  Key  Compromise  (also  see  Section  10.2.4) or no longer complies with the requirements of Appendix A;
  The CA obtains evidence that the Certificate was misused;
  The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber or Terms of Use Agreement;
  The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain
  Name Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);
  The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
  The CA is made aware of a material change in the information contained in the Certificate;
  The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;
  The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
  The  CA  ceases  operations  for  any  reason  and  has  not  made  arrangements  for  another  CA  to  provide revocation support for the Certificate;
  The CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
  The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate;
  Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
  The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers  or  Relying  Parties  (e.g.  the  CA/Browser  Forum  might  determine  that  a  deprecated cryptographic/signature  algorithm  or  key  size  presents  an  unacceptable  risk  and  that  such  Certificates should be revoked and replaced by CAs within a given period of time).


Ensure input escaping in JSP All user input should be escaped.
But unfortunately when using JSP we have to do this exlicitly by using
Often unexperienced developers just use ${value}, which just writes the value without escaping.

Is it possible to escape all values which are written by ${value} per default?

Otherwise, is there a static code analysis tool which finds uses of ${value} without c:out ?

All user-supplied input should be validated on entry (use Hibernate Validator with its @SafeHtml annotation), so you don't fill your database with potential XSS that could wreck another application, or later versions of the same application

You could use my crude tool to validate all GET & POST parameters and header names and values:

http://blog.databasepatterns.com/2015/08/simple-inbound-xss-filter-for-spring.html

Heads up: it doesn't validate request bodies

User-supplied data should be escaped on output as well

You can use this Expression Language resolver to "auto" escape all JSP pages https://pukkaone.github.io/2011/01/03/jsp-cross-site-scripting-elresolver.html


WebDAV automatically attempting to connect remotely because of DFS namespace? I recently bought and Installed a WAF (after much begging).

I have a DFS namespace called \\mycompany.com\ which is based on my Active Directory domain name mycompany.com. My website domain is mycompany.com

Users are mapped to DFS namespace \\mycompany.com\ourfiles\etc\

Now my WAF is reporting a generic attack disclosure from IPs originating from my surrounding geographic area pointing at mycompany.com\ourfiles\etc\ Using Microsoft-WebDAV-MiniRedir/6.1.7601 (which is a Windows 7 WebDAV if I remember) over HTTP. I assume from users that took there laptops home.

Sometimes the folder path showing up is very specific, however not out of the ordinary for someones shortcut.

My question is how should I tackle this? I know the WAF will report just about anything odd. I am able to easily replicate this report by manually trying to map a network drive outside my network. \\mycompany.com\files\etc\

When I try to use a domain joined system from an external WAN to try to replicate this issue without manual mapping I am not able to. Also WebDav or Windows Authentication is not installed on the web server.

Edit: For clarification is there a security concern here? or is it completely benign?

I believe that Win 7+ will automatically attempt to connect to a WebDAV service if it's link formatted as you have it, thinking that the service is on a remote system somewhere. (IE under a mapped drive doing something like \\example.com\folder\ will trigger MS to look for external services in that domain using WebDAV)

Method 1

If you have no WebDAV service for external users, just filter out all WebDAV traffic. Let it get logged and you can probably lower/disable the notification threshold.

Method 2 - Not recommended

I believe Windows has a way to disable WebDAV on the Laptops. This might invariably break something else, but it's worth looking into if your company doesn't use the service. (This will create a user complain train if it breaks something they use frequently, company related or not)

Security Concerns

If your company doesn't rely on WebDAV for anything and you block all inbound communication of WebDAV traffic you have minimal impact. There isn't anything really pressing about the WebDAV triggers that makes you go, OMG WE'RE DOOOOOMED, based on you initial analysis of it (I think you right to assume they are false positives). At this point it's baseline for you to look at, unless an attack has active knowledge of your directory structure, trying random WebDAV request will be pretty obvious even among the false positives.

In short, your pre warning will be hindered slightly, if you get accustomed to seeing tons of false positives.


Software activation "by phone" I'm a software developer, and I would like to protect my application in an offline way, like many software do activating by phone.
Following a screenshot taken from google images on what I would like to achieve:

I'm interested on how this functionality works from a security point of view. What I've supposed should work like this (please correct me if I'm wrong):

The application generate a random code and shows it to the user
The user phone the application provider and communicate the code.
The company checks the user identity: we can suppose I can securely check the user identity.
The company own a private key, the same stored in the application, so with an internal software concatenates the random code given by the user with the private key, generate a cryptographic hash (e.g. SHA-256 hash sum (SHA-2)) and communicate the result to the user.
After the user insert that code in the form, the application checks that the given unlock code is equal to the one it has internally calculated.

Does it work like this?

The private key won't be stored in the software. If a private key is used, then the corresponding public key will be stored in the software. See Wikipedia - Public-key cryptography.

If you used a symmetric crypto algorithm it would be "easy" to extract the key from the software (security by obfuscation does not count) and calculate the confirmation ID by yourself. Even worse, anyone could provide tools to calculate the confirmation ID.

Hence I would change step 4 and 5 a bit. I would indeed hash the Installation ID and then cipher it with my private key - this is the Confirmation ID. The client would then decipher the Confirmation ID (with the public key) and compare the result with the hash it calculated from the Installation ID. If the hashes match the Confirmation ID is correct.


Truecrypt hidden partition deleted original drive data Help! I created a hidden partition within a harddrive encrypted using truecrypt, and instead of creating a second partition, it seems to have deleted all of my data instead. what did i do wrong? I simply followed the instructions on creating a hidden partition. my only mistake was using the same password as the outer partition. however, it still should have opened the normal partition, since truecrypt tries to open that first, but all im getting is an empty harddrive. it had some data on it that i would rather not lose.

how can i delete the partition, or at least make truecrypt see the top partition, instead of going to the hidden partition?

edit: i changed the password to the outer partition, but the harddrive is still empty. i can access the hidden partition with the old password, but it is not formatted

@gowenfawr seems to be correct here, but let me try to clarify exactly what's happened.

First, some quotes from TrueCrypt's own documentation on Hidden Volumes:

  The password for the hidden volume must be substantially different from the password for the outer volume.

and

  TrueCrypt first attempts to decrypt the standard volume header using the entered password. If it fails, it loads the area of the volume where a hidden volume header can be stored

Now, here's what (I believe) happened in your case, step-by-step:

You created, formatted, and stored data on a TrueCrypt volume, which for the sake of this walk-through we'll call "OuterVolume".  Also, for the sake of this walk-through, we'll say you used (please, don't ever) "Password1" as the password.  And, let's say you decided to store this within a file called "MyVolume.tc".
Then, you attempted to create and format a Hidden Volume which, for the sake of this walk-through, we'll call "HiddenVolume".  You created HiddenVolume within OuterVolume and used "Password1" as the password.

Here's where things got borked.  When TrueCrypt went to open HiddenVolume to format it, this is what (I believe) happened.  This may have been step-by-step as you executed it, or some of it may have just happened in the background:

When attempting to open HiddenVolume for its initial formatting, you pointed TrueCrypt at MyVolume.tc and gave it the password of Password1.
TrueCrypt attempted to decrypt the first volume header (which would be the one for OuterVolume) with the given password.
Since Password1 is also valid for OuterVolume at this point, the header decryption was successful and TrueCrypt stopped looking for other headers.  It then used the key to finish decryption of OuterVolume.
With OuterVolume having been mounted, but you believing it was HiddenVolume, OuterVolume was then formatted and HiddenVolume was left untouched.

Now, to explain what's happening after the password change:

For the sake of this walkthrough, you changed the password to OuterVolume, to "Password2".
You attempted to mount MyVolume.tc with Password2, and succesfully opened OuterVolume.  Now you see that OuterVolume was formatted earlier, when you thought you were formatting HiddenVolume.
Then, you attempt to mount MyVolume.tc with Password1.  Since TrueCrypt can no longer decrypt the first header (for OuterVolume) with this password, it now moves to look for the space where a Hidden Volume's header might be.
TrueCrypt successfully decrypts HiddenVolume with Password1, and now you see an unformatted volume because, after all, HiddenVolume was never itself formatted.

It should be clear by now, that all of the data previously stored in OuterVolume is more than likely lost forever.  I know of no software (though it's imaginable, I doubt it exists or is within the realm of common affordability) that can perform any sort of undelete on an encrypted volume, let alone one which has been re-keyed.  If you would still like to work with HiddenVolume without nuking MyVolume.tc entirely, you just need to make sure that the keys for OuterVolume and HiddenVolume are significantly different and then reformat HiddenVolume.  Additionally, TrueCrypt recommends:

  To the outer volume, (before creating the hidden volume within it) you should copy some sensitive-looking files that you actually do NOT want to hide.


On-line cryptographically signed date/time? I’m looking for a source of on-line cryptographically signed date/time. I do not need a full timestamp service, as I am happy with the information « date/time was that », without a link to a challenge/hash that I provide. I do not care if an active adversary feeds my trusted device an old (even very old) date/time ; I’m only concerned with attempts to feed it a date in the future. My trusted device could be a Smart Card that I can program, connected to an untrusted PC.

I would like something with no fee or need to authenticate in order to obtain a new certificate. I'm OK for a yearly fee to the authority providing me that service. I anticipate a mere ten thousands requests over a year. I could live with service interruptions or date/time lag not exceeding an hour.

I’m thinking of purchasing a regular SSL (or similar) certificate from a commercial CA, and using the revocation services they provide for that certificate, which I’m told respond to queries « is this certificate still valid? » with a signed  message « by (explicit current time) this certificate is valid », that I’m then able to check using the long-term CA public key.

Does that seem sound? Which suitable protocol is widely supported by commercial CAs? Is my usage allowed by normal commercial CA practices/term of uses?

Any alternative?

Late additions:

I'd very much prefer something such that the trusted device can verify a moderate amount of data (e.g. signed message, certificate), statically submitted to it by the untrusted PC host.

The job of the trusted device should be simple (due both to limited resources, and the need to ascertain that the implementation is secure).

I would prefer that the cryptographically signed date/time could be obtained in a single TCP/IP session, and I'm not ready to setup an email address per point where I need this service.

My requirement for free requests is not so much about the fee, but about the practical need to authenticate in order to request anything obtained for a fee. A password is out of question. Even a weak authentication by IP does not fit (switch to a backup internet access in an emergency and poof goes the availability).

I have nothing against a free service, but I'm willing to pay to lower the odds that the service is terminated, and make someone embarrassed if the clock jumps in the future.

I think you could use any web site operated by a reputable company that supports access over SSL. The one quirk is that the list of certificate authorities that might sign their certificate could change.

For example if you retrieve https://www.google.com/ you'll get something like:

HTTP/1.0 200 OK
Date: Tue, 06 Dec 2011 17:02:40 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
...

Notice the Date header right in there?

If you're paranoid, you might want to maintain a list of possible web sites to access, just in case something happens to one of them.


Indicator of Compromise effective periods How long should IOCs be monitored even thou they might be "outdated"? Are there best practices or other reasonings?

I would think monitoring IOCs indefinitely is not ideal. Perhaps 90 days would suffice?

Example: An IP IOCs will not be effective after some time as the IP address might have been changed. Likewise for domains IOCs.

Malware analysts are often asked to correlate IoCs retroactively. Recently  correlated IoCs that went back to Chinese code from 2002 in 2016. Just a few months ago, we found meaningful IoCs that tied a threat commnunity to its predecessors from 2006. Without the ability to track all of these IoCs across the years, there would not have been a correlation.

There are also ways to grade IoCs:

Level 1 : SHA2 hashes, BGP ASNs, hostnames
Level 2 : MD5+SHA1 hashes, IPv4/IPv6 Prefixes
Level 3 : Mutex names, Imphashes
Level 4 : Yara rules
Level 5 : File, class, or block similarities (e.g., Icewater, GCluster.py, TLSH or ssdeep fuzzy hashes)
Level 6 : Apiscout and master-level malware analyst techniques

Malware tends to bypass all of the above in different manners. Some malware can even lie to or bypass all of the above, simultaneously. You definitely want to scale your IoCs when working against that threat space. However, you’ll also want to take into account factors that computers cannot scale —- the human element, surprise, and indications.

Perhaps you mean, how long should you monitor IoCs on the network? Or do you mean in sweeps across a fleet?

If you are looking for a way to manage IoCs on the network, check out the Bro Intelligence Framework. For fleet management of IoCs there are a few tools, such as Viper to database and view classic IoCs, YaraGuardian for organizing and searching Yara rules, Timesketch to play with the data, as well as ways of gathering artifacts and mining/monitoring log data.

There are many ways to approach artifact and log collection, in addition to monitoring, analysis, and synthesis. I like how these professionals outline 3 approaches —- https://posts.specterops.io/thoughts-on-host-based-detection-techniques-21d9c97082ce —- especially through their toolsets such as Automated Containment and Enrichment (ACE Server), Hunting ELK (HELK), and UpRoot. You’ll see the techniques from these toolsets in commercial platforms, such as Infocyte, Splunk Enterprise Security, and Carbon Black Cb Response, respectively. If you really want to scale fleet sweeps of IoCs, then the ACE Server, InfoCyte, and maybe even the PowerForensics or PowerShell Kansa tools are my first-round suggestions.


Is laptop "secure sleep" mode theoretically possible? For laptops with full disk encryption or home folder encryption, one of the risks if it is stolen while in sleep mode is that the encryption key is stored in memory and can be read if an attacker knows how.  To me, it seems that, in theory, operating systems should be able to have a "secure sleep" option where the key is erased from memory prior to sleep mode, and on resume, the user must provide a password to unlock the encryption key, as through a cold boot.  All processes except the lock screen would be prevented from continuing until the encryption key is restored to memory.

I realize that this would mean that the computer cannot do any scheduled tasks in sleep mode, but most users probably wouldn't care about that.  And maybe drivers or other obstacles would prevent this from being realistic.

Are there any reasons why a "secure sleep" option cannot be easily implemented?

Yes. It could be easily achievable, although it would require kernel support do this properly.

In the suspend-to-RAM case, the key should be deleted from the RAM, and in the suspend-to-disk case, from the RAM and also from the disk (or it can be stored encrypted on the disk).

A minimal input should be also provided to get the key/reauthentication credentials in the early boot/wakeup stage.

I don't see any technical obstacles; the probable reason that it wasn't developed until now was the lack of interest. Scenarios where direct RAM access of a working laptop is a real security risk are very rare.


What is the current security status of Diffie-Hellman key exchange? There is a web site weakdh.org, whose name alone would certainly cause some feeling of uncertainty in using DH among people who are not experts IMHO. Could some knowledgeable person kindly say something of the current security status of DH, i.e. what are the major precautions, if any, that one has to be aware of in applications of DH today?

I'm especially interested in the minimum key size needed for use in SSL, but will appreciate additional information.

The weakdh.org Web site is about the Logjam attack. Contrary to what the Web site name may suggest to the unwary, this is not about DH being weak; it is more about doing things weakly when using DH.

Diffie-Hellman works in a multiplicative subgroup of integers modulo a given prime p. To do some DH, you use some DH parameters which are:

p : a big prime, called the "modulus"
q : a divisor of p-1, called the "subgroup order"
g : an integer modulo p of order q (this means that the smallest integer k > 0 such that gk = 1 mod p is k = q)

For DH to be safe, you need the following:

p must defeat attempt at discrete logarithm through Index Calculus. This means that p must be large enough, and also must not have any "special structure" such as being very close to a power of 2, because such structures allow for improvements in Index Calculus. It so happens that size requirements for DH are about the same as the size requirements for RSA, though the underlying reason for that is intricate and partly coincidental. So, basically, use a random p of 2048 bits, and you will be fine.
q should be prime or have a prime divisor whose size is enough to defeat generic algorithms for discrete logarithm. If the size (in bits) of the largest prime divisor of q is z, then generic algorithms have a cost in 2z/2. For best results, arrange for q to be a prime of 256 bits or more.
Systems that use the parameters to perform a DH key exchange must generate a random integer between 1 and q-1 uniformly, using a cryptographically strong source of randomness, of course. If q is prime and larger than 256 bits, it suffices to choose a 256-bit random value to achieve 128-bit of security. However, if q is not prime, things are more complex: if q has size r bits, and the largest prime divisor of q has size e bits, and e ≥ 256, then one may choose a random value x of size r-(e-256) bits to get the usual "128-bit security".

When p is a so-called "safe prime", then p = 2r+1 for a prime r, so for any generator g that is not 1 or p-1, the order of g will be either r or 2r, so it suffices to generate DH secret keys x as random 257-bit values. The "safe primes" are not actually any safer than other primes, except for that point: they tolerate the choice of relatively small DH secret keys for any generator.
Last but not least, DH is a key exchange algorithm that does not, inherently, provide authentication or confidentiality. DH is "safe" only when used within a protocol that uses DH and other algorithms with proper integration to achieve such sought after characteristics as data confidentiality and integrity.

Speaking of which, some (many) SSL/TLS implementations did things improperly, in that they gladly accepted to do DH with weak parameters, in particular a 512-bit modulus. The protocol itself is suboptimal in its handling of DH because the ServerKeyExchange message allows the server to send the DH parameters p and g to the client, but not q, leaving the client a bit in the dark. Thus, the client must either "play safe" and generate its key in the full 1..p-1 range, or try to use a shorter exponent (say, 256 bits, not 2048) for a reduced computational cost, but possibly at risk of weakness in case the subgroup order q is not prime. A better design would have allowed the server to send the value of q and the size of the biggest prime divisor of q. In that respect, the ECDHE cipher suites of SSL/TLS (DH translated to elliptic curves) have a better design.

For a practical answer if you are configuring your SSL/TLS server: you should use a modulus of at least 2048-bit, and a generator g such that the order of g is a prime q of at least 256 bits; alternatively, you may use a modulus p which is a "safe prime" (the order of g will then be either a very big prime, or twice a very big prime, which is almost as good). Some people feel safer when they generate their DH parameters "themselves"(*) instead of reusing existing values; if that's what it takes to allow you to sleep at night, then do it.

(*) People never generate their DH parameters themselves; they use a computer. But we are talking psychology here anyway.


How does Matrix SSL perform certificate validation? We use a custom app which uses Matrix SSL (client side) to perform certificate validation on MAC and Linux systems. My question is, does Matrix SSL keep a cert store cache of intermediate and trusted roots so it can perform its checks against what the server sends? Or does it call up something like OCSP or use AIA extensions like browsers do in order to validate the chain? Or can Matrix SSL be developed to use both methods?

After having a look at the documentation of MatrixSSL I assume that:

Since it is transport layer agnostic it will not (and can not) retrieve missing intermediate certificates by itself. To do this it would need to have some kind of HTTP client (maybe with proxy support to) and I cannot see any such thing documented.
It will also not check by itself, that the hostname matches the certificate. You need to add your own certValidator to do this. If you don't verify the hostname in the certificate you will accept any certificate signed by a trusted CA for an arbitrary host, which will effectively leave you open to man-in-the-middle attacks. That means implementing this is a must, unless you need to check only against some fixed certificates (i.e. certificate pinning).
The API contains functions for CRL handling, but requires the developer to provide the CRL itself. It has function to get the URL for the CRL but the developer than has to retrieve the data for the URL by itself.
There is no documented API for OCSP. Since OCSP requires HTTP access and since MatrixSSL itself is transport agnostic it can be assumed, that it will not do OCSP lookups by itself and will also not give the developer the necessary information to do OCSP lookups.

At the end this is about the security you get from OpenSSL, i.e. no hostname checking, only manual CRL, no documented API for OCSP (although there is an undocumented but fairly complex API in OpenSSL).

Since you are using MatrixSSL only for your own custom app I would recommend to keep it simple and secure by only accepting few specific certificates which are controlled by you and which are hard-coded inside the application. In this case you would not need the more complex stuff like hostname or revocation checks.


Does TLS hash passwords before encrypting? Suppose I am logging into Gmail by giving my credentials. Does my plaintext get encrypted or is it first converted to the hash and the hash encrypted?

And also if I am communicating to the bank web server and I am doing transactions, is the bunch of packets first converted to a hash and then the hash is encrypted, or is the plaintext of the packets encrypted?

If you connect to the server via TLS, then all your communication, including your credentials, will be encrypted.

Once the server has received them, the server will decrypt your credentials, then hash them, and then compare that hash to what is stored on the server. If it matches, you will receive some authentication token to indicate you are authenticated. If it does not match, you will receive an error.


Remove adf.ly malware A malware redirects my page browser to adf.ly website page that requires me to wait 5 seconds and then click skip ads to get to my page. I tried the following things:

I scanned my PC with most of malware program
Reset Chrome, mozilla and all browser
Removed cookies and temp

Finally I changed my windows and the first thing before setting up any thing checked this with internet explorer and was shocked that the malware still infected my PC.

Please i need quick help. I can’t work or search for anything.

First of all, check your browser settings. Make sure your home page is google.com ( for example). After that, download adblock, with that plugin you can block sites, ads, etc... Add adf.ly to blacklist, and i belive problem will be solved.


Writing your own John the Ripper module I have a script in C, which is able to determine the password of certain data. It uses HMAC and RC4 algorithms to encrypt the given  password and then compares that later to the given data. If they are the same, the given password was the original one.

Now I want to implement this method into a John Module to use their speed and environment for dictionaries etc.

I've already read the format.h and some other modules, but I'm still a little overwhelmed where to start.

Could someone give me an outline on what or how I need to write and implement my own John Module?

Update: I've found a fmt_plug file that could fit my needs: This one. But now I'm stuck at the next step. How does John reads the files. It seems like most formats use different formatted files with either a username and/or a salt and always a hash of course. But I cannot find any declaration how the file should be read inside the fmt_plug.c files.

I was thinking about formatting my files with $fmt_name$username#hash1#hash2, because I need to split the hash in 2 parts to use some algorithms on the different parts.

How would I tell John how to read my files?

John The Ripper seems to welcome external contribution especially through their "Jumbo" aka "community enhanced" version of the software instead of the mainstream one.

It is described as having a lower quality standard, but easier for patch integration allowing more people to integrate new modules in a more convenient way which, I think, is precisely what you are looking for.

You should start from there. It contains already a bunch (a hundred according to the main site !) of modules you can take as sample, a page with patch-related documentation, and in case all this is not sufficient advice you to get in touch with the John mailing list for even more help.


Will Let's Encrypt require SNI from the operators? I'm curious if anyone knows whether the upcoming Let's Encrypt initiative would effectively require SNI.

What I mean is, with the proliferation of the cloud, almost every web-site owner, even with the smallest possible web-site, has their own IPv4-address.  However, every such owner may have several unrelated web-sites on a given IPv4 address as above.

Currently, it would appear that the CA cartels make it cost prohibitive to obtain a single certificate with several distinct CNs specified, making it cheaper to rent extra IPv4 addresses if non-SNI clients must be supported.  Will Let's Encrypt be the same, or do they plan to support multiple unrelated CNs per certificate, avoiding the need for a choice between SNI and IPv4-address waste?

According to the post (dated 2015-09-09) in the subjectAltNames certificates thread: yes,  subjectAltNames for unrelated domains will be allowed.

Update (from more recent posts in the thread links above):

Users report practical success in generating certificates with multiple domains. There is apparently a limit of 100 names per certificate.


nmap's -sn flag works when a single target is specified, but, not when multiple targets are When I specify an individual target,

>nmap -v3 -sn 172.18.188.209

I get the correct and expected nmap response

Starting Nmap 7.70 ( https://nmap.org ) at 2019-11-08 11:16 India Standard Time
Initiating Ping Scan at 11:16
Scanning 172.18.188.209 [2 ports]
Completed Ping Scan at 11:16, 1.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:16
Completed Parallel DNS resolution of 1 host. at 11:16, 5.62s elapsed
DNS resolution of 1 IPs took 5.62s. Mode: Async [#: 4, OK: 1, NX: 0, DR: 0, SF: 0, TR: 3, CN: 0]
Nmap scan report for raspberrypi-dQ2XyAPpB6.dhcp.XXXX.com (172.18.188.209)
Host is up, received conn-refused (1.0s latency).
Read data files from: C:\Program Files (x86)\Nmap
Nmap done: 1 IP address (1 host up) scanned in 6.70 seconds

However, when I specify a range,

>nmap -v3 -sn 172.18.184,186,188.0-255

I get,

.
.
Nmap scan report for YYYY.dhcp.XXXX.com (172.18.188.208)
Host is up, received syn-ack (0.0010s latency).
Nmap scan report for 172.18.188.209 [host down, received no-response]
Nmap scan report for 172.18.188.210 [host down, received no-response]
.
.

I'm running Windows 10 version 1809 build 17763.737 and Nmap 7.70

Additional info if it helps

>nmap -version
Nmap version 7.70 ( https://nmap.org )
Platform: i686-pc-windows-windows
Compiled with: nmap-liblua-5.3.3 openssl-1.0.2n nmap-libssh2-1.8.0 nmap-libz-1.2.8 nmap-libpcre-7.6 WinPcap-4.1.3 (packet.dll version 10 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: iocp poll select

Is this a bug, or am I missing something in the switches ?

Thanks !

Have you tried upgrading to Npcap instead of WinPcap? Nmap comes bundled with it, though you can and should get the latest stable and bug-free version from https://npcap.org/#download . It is faster than WinPcap and designed for modern versions of Windows, so you should be less likely to see problems like lost packets.

Your Nmap is also out-of-date, though only by 1 release. I'm not aware of any specific bugs that would be causing that behavior, but our advice is always to upgrade before making a bug report in case the issue is solved in a later release.


What is the difference between "cipher" and "encryption"? It seems as if they are either synonyms, or cipher was an older term for when they directly translated the same number (or almost same number) of "encrypted" characters into the same number of plaintext ones, whereas encryption means that they use such a complicated "algorithm" as to make it impossible to deduce the length of the message from just seeing the "encrypted blob", which uses highly complex "back-and-forths" to produce the final decrypted string.

"Cipher" is the algorithm or process used to encrypt the data (i.e. AES, RSA, etc.). "Encryption" is the process of converting data using the aforementioned cipher.


msfconsole and using bash variables When trying to set RHOSTS for an auxiliary module, I tried using $server, which is a bash variable I've set before entering msfconsole. It is not readable from within msfconsole.
How do I access bash variables from msfconsole?

Keep in mind that metasploit do not contain all bash functionality. It has some basic commands like ls or ping but I am not sure if you can use full bash inside. You can try to create a script of echoing the variable and simple copy paste can do the job.


Proper way to verify keycard integrity I have thought about building an electronic door locking system.

Would the following mechanism be secure at all to prevent tampering plain text information on card?

hash private system key together with cardholder data
save the hash and card holder data to an RFID card
the lock (which only has the private key) takes the cardholder data and hash when authenticating
the lock creates a hash using it's private key (the same used in creating the card) and plain text data from card.
Lock compares the hash it generated to hash on the card

Any particular vulnerabilities other than brute forcing?

A hash can be copied by brief access to the smart card. This approach is basically the same as comparing strings; crypto adds no real benefit in your scenario - only obscurity, as anyone with access to either the private key or the hash will be able to authenticate. It will also be vulnerable to simple replay-attacks.

Modern RFID cards acts as smart cards. Store a private key in the smart card, and ask the smart card to authenticate to the reader, using these keys. Smart cards are commonly set up not to hand out their key, only use it for processing.

By using proper crypto you'll essentially make a system that is secure, as long as there is no security problems in the smart cards, allowing copying of keys. It will typically protect against replay attacks as well, as the data the card manipulates will change for every contact.

It's also worth reading about zero-knowledge proof on wikipedia. In brief, there's several methods within cryptography to prove that you know a secret, without ever revealing the secret to anyone. PKI is one obvious way; by signing you prove that you have the private key, but not the content of the private key.


How does a server validate the Certificate Verify message in SSL/TLS? Client authentication may be used in a SSL/TLS negotiation.
For this, the client will send a CertificateVerify after the server requested it.
The CertificateVerify message contains the client certificate that will be verified by the server.
How does the server verify that the client certificate (containing the client public key) is legitimate?

The handshake part of the TLS 1.3 protocol has three goals:

exchange certificates;
let the server confirms that the client really have the secret key associated with the provided public certificate, without exchanging the secret key;
exchange ephemeral keys.

Part 1 - Trust of certificate

Client sends its certificate with Certificate message.

Server determines if the certificate is from trusted source. It verifies the signature of the client's certificate, then the signature of each intermediate certificate, until it finds a trusted certificate, either from a server-side list of trusted certificates, or from a trusted certificate authority (CA).

Pseudo-code:

Alice (client) sends her public certificate to Bob (server) as well as the certificate chain.
Bob hashes the certificate.
Bob decrypts the certificate using the upper-level certificate in the chain.
Bob compares the two results; if they match, Bob has the proof that the certificate was really signed using the upper-lever certificate.
Bob continues through the chain (steps 2, 3, 4) until it finds a trusted certificate.

Part 2 - Trust of client

The client sends the Certificate Verify message:

struct {
  SignatureScheme algorithm;
  opaque signature<0..2^16-1>;
} CertificateVerify;

The signature scheme tells hash function used and signature algorithm.

The signature is produced by the client and verified by the server. The data actually signed is known by client and server and thus not re-sent (it's spaces, a context string, a zero byte and the previous messages).

Pseudo-code:

Alice (client) generates an asymetric key pair.
A trusted authority signs her public key, producing a public certificate.
Alice hashes the data.
Alice encrypts the hash using her encryption key (her private key).
Bob (server) knows, from a previous message: Alice's public certificate and the certificate chain.
Alice sends to Bob: signature, hash function and signature algorithm.
Bob hashes the data.
Bob decrypts the signature using Alice's public certificate.
Bob compares the two results; if they match, Bob has the proof that the signature is associated with the data and Alice's private key generated the signature.

Now, Alice must keep her key secret, and the data must vary between requests to avoid Eve from replaying the request with same data and same signature.

I hope it helps you to better understand.

References:
http://www.garykessler.net/library/crypto.html#why3
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html
https://nodejs.org/api/crypto.html#crypto_class_sign
https://www.tutorialspoint.com/cryptography/cryptography_digital_signatures.htm


VirtualBox: Opening appliance with 7zip We have a PHP application that is inside a virtual machine (turnkey VirtualBox). We developed an installer that downloads virtualbox and imports the appliance. The user executed this installer to get the app.

But, we discovered that if the user has the 7zip and opens the appliance (.ova) he can navigate by the folders and get the PHP Code.

What can we do to block this "navigation with 7zip"? Like an appliance "encryption" or something like this.

Thanks!

But, we discovered that if the user has the 7zip and opens the appliance (.ova) he can navigate by the folders and get the PHP Code.

An .ova file is simply a tar file containing configurations and disk images for the appliance. 7zip allows the user to open the tar file and since 7zip supports various disk image formats the user can also look whats on the disk, i.e. your PHP files.
There are other ways to do this without using 7zip so it would not make any sense to develop any 7zip specific solution.

The cause of the problem is that you distribute the source code of your application to the user, even it is packed inside multiple containers (disk image, tar). You do this because your web application in the appliance needs to have access to these files. Encryption of the .ova or disk image inside will not help because in order to run the application these data need to be decrypted and once this is done the user can again access the data.

It is also not possible to encrypt the PHP code itself because the PHP interpreter needs the decrypted code. The best possibility to hide the code from the user is probably to obfuscate it so that it is still usable source code but unreadable enough for simple reverse engineering.

At the end you face the question tools like DVD players and other DRM solutions faced before: once you have shipped the application to the use you loose the control over it. As long as you have no control over the system of the user you can not limit the activities of the user. This means you can make the reverse engineering only harder but not impossible.


Who uses 1024-bit RSA? I know they're deprecated, but does anyone still use 1024 bit RSA encryption or certificates? Do you know of any examples of systems that use it today? What would be the implication if someone factored RSA-1024?

Well I pretty much answered the question already in the comments but now I'll do it as fully qualified answer.

Yes, 1024-bit RSA moduli are still in use. The samples I could quickly find are the Equifax CA certificates in Firefox. Those will be removed soon.

What would happen if someone factored any of these moduli?
Really bad things.
If you factor any of these certificates you can impersonate a widely trusted CA. This means you can issue valid certificates that will be widely accepted. The only defenses are DANE (not widely deployed yet) and certificate pinning (not possible to be widely deployed).
More practically this would mean, that you could impersonate any given server on the web (provided you can forward DNS requests to your server), as you can issue (EV?-)certificates on any site like maybe google.com, amazon.com, paypal.com, security.stackexchange.com, ... Even further you may be able to issue code-signing (EV?-)certificates, which would enable you to digitally sign malware, so that it can be installed as kernel-mode driver in Windows!

If you don't attack those CA's certificates but rather "normal" server's certificates you can easily decrypt any traffic that uses the RSA as key-exchange algorithm and you can start active man-in-the-middle attacks against those servers and easily read any traffic even if (EC-)diffie-hellman key exchange is used!


Is it safe to host passwordless web applications/software with web GUI in Virtual Machines I have a Linux Mint Virtual Machine which I use quite a lot with my Windows host. I have lots of Software installed there (mostly with web GUI so I can access them from host easily).

So I am wondering instead of securing individual applications (by adding username/password, limit incoming request from host IP), can I just add a firewall which will limit incoming requests only from host IP? Will it be safe?

Using either the Windows (host) firewall or the guest OS firewall to do that is not recommended.

All VM tools already provide that kind of control. Have a look at the different types of networking available. You want a host-only network. By design that can only be used between the host and the VM, it is never accessible outside the host.

I should also have said that if you also need some services to reach outside the host, you can have both by setting up 2 networks and binding your web services to the host-only network.


RSA 4096 with AES 256 Encryption Process Using PyCrypto I have the following process for encrypting and decrypting data in a python script using the PyCrypto module:

Encryption - Server A

AES 256 shared key is generated
Associated IV is generated
Data is encrypted using AES 256 shared key and associated IV using CBC mode and stored into the db
RSA 4096 public key is used to encrypt the AES 256 key and associated IV which are also stored in the db

Decryption - Server B

Encrypted AES 256 shared key and associated IV from db are decrypted using RSA 4096 private key
Data from db is now decrypted using the decrypted AES 256 shared key and associated IV

Does the above process ensure the security of data against an attack model where the attacker has managed to gain access to the database?

My main feedback: You don't provide enough technical detail to provide a complete critique of your proposal, but you have provided enough information that I can see that you are making several common mistakes.  Here are the main mistakes I can see so far:

Mistake #1: inventing your own encryption format.  Usually, designing your own format for storing encrypted data is not a good idea; you are likely to get something wrong.  It is better to use a standard format, like GPG or the OpenPGP Message Format.
Mistake #2: failure to include message integrity protection.  Encrypting data without also authenticating opens you up to subtle but serious attacks.  This is highly counter-intuitive, and a very common mistake.  It is tempting to think, gee, I want to keep this secret, so if I encrypt it with a good encryption algorithm, I'll be fine.  But nope, you won't be fine.  You also need message authentication, to defend against chosen-ciphertext attacks.  And you need to apply with a proper mode (e.g., authenticated encryption, or Encrypt-then-MAC) and with proper key management (independent keys for authentication and encryption, or appropriate use of key separation).

To avoid these problems, follow the advice at the links I gave above.

Other miscellaneous feedback:

There may well be other problems; you haven't provided us enough information to identify them all.  Here are some examples of potential problems:

For instance, you don't describe how the IV is generated.  In past systems, poor IV generation has occasionally led to security problems.  (The IV needs to be generated using a crypto-strength pseudorandom number generator.)
You don't describe how the AES key is encrypted.  (You need to use a proper padding scheme, e.g., OAEP or PKCS#2.)

The key lengths you have selected are overkill.
Keep in mind that, when modern cryptography is properly implemented and used, it is almost never the weakest link in the system.

Instead, attackers usually defeat crypto not by breaking the crypto algorithms, but by bypassing the crypto and attacking some other aspect of the system -- maybe applying social engineering to the humans, maybe finding a security hole in the code and compromising an endpoint, maybe exploiting errors in the key management, or any of a number of other ways of attacking a system.


Internet monitoring and DNS encryption If someone hides their DNS traffic by encrypting it with a service such as OpenDNS's DNSCrypt, would you still be able to see which URLs they're viewing?

Also, if that person uses HTTPS 100% of the time, can you tell which pages they access?

Or would sniffing their packets show which pages and sites they were accessing as usual?

Yes, if you're watching the traffic, you can still tell which address a person is connecting to whether or not you can see the contents of that traffic. That's the nature of IP packets. There's no way around it. Then it's just a matter of doing a reverse-lookup on the destination IP to see it's owned by Facebook or Twitter.

You can shift the problem elsewhere by using a VPN to connect to some "safe" location, perhaps at work, perhaps at a datacenter. If all your IP traffic is tunneled over that VPN, then someone watching the tunnel can't tell what sites you're visiting.

However, someone watching the traffic at the far end of the tunnel, perhaps at your datacenter or at your office, is again able to see the traffic and make usage judgements just as your ISP can now.

Tor works on the same principle as a VPN, except that with Tor, the VPN is to some unknown endpoint somewhere out on the Internet, following a series of unpredictable hops that's difficult to trace.


On Windows boxes, is patching for Spectre and Meltdown necessary? From what I've read, Spectre and Meltdown each require rogue code to be running on a Windows box in order for attacks to take place.  The thing is, once a box has rogue code running, it's already compromised.

Given that the Microsoft patches for Spectre and Meltdown reportedly slow down the patched systems, it seems like possibly a good decision to leave Windows systems unpatched at the OS level.

Assuming rogue code is not installed on a Windows box, the only point of easy penetration to a system seems to be via javascript running in a web browser. Yet both Mozilla's Firefox and Microsoft's Internet Explorer have already been patched.  Google's Chrome is not currently patched, but it can reportedly be run in strict site isolation in order to prevent successful Sprectre and Meltdown attacks.

Given all the above (and assuming best practices of not running unknown code), does it really make sense to patch Windows for Spectre and Meltdown?

the only point of easy penetration to a system seems to be via javascript running in a web browser.

How about Flash? Java? Silverlight? VBA in an office document? Any applications that load web-pages inside of themselves?

  The thing is, once a box has rogue code running, it's already compromised.

With code running under your user account a lot can be done. But compromised is a relative term. You can't for example install a low level key logger. Permissions might stop you from reading other applications memory space even when run under the same user account. And of course you have no access to files and processes run under other user accounts. A user on a corporate machine could not hijack another logged in users session.

Being able to read arbitrary RAM values can give you the access tokens required to defeat all of this.


Secure connection over a Unencrypted Proxy is secure? I have my code sending a request to a URL such as:
https://www.example.com
while connecting over a proxy, with the proxy URL being:
http://www.example_proxy.com

Since my site is using HTTPS and my proxy is using HTTP, is this a problem? Please explain if this is secure.

This can be secure.

The client can issue a CONNECT request to the proxy, which basically creates a tunnel between the client and the destination server. This way, the client can set up an SSL connection through the proxy, and the proxy will see encrypted traffic. Even if someone else impersonates the proxy, he will only see encrypted traffic.

Another possibility is to do a GET request to the proxy. This asks the proxy to retrieve a page on your behalf. This is usually only used for HTTP traffic, but may also work for HTTPS traffic. If your client uses this method to retrieve a page, the proxy can view all data. Furthermore, a man-in-the-middle attacker may impersonate the proxy and also see all data.

If you use an HTTPS connection to the proxy, it is much harder for a man-in-the-middle attacker to impersonate your proxy.


Data visible when intercepting traffic even though SSL is used Why do I still see data passing by when the traffic is encrypted? I use packet capture to intercept the traffic of mobile application within my phone. Sometimes I do see garbage values and sometimes API destination along with garbage values.

Its because the API destination cannot be hidden by SSL.
Whats hidden by SSL, is the data, eg the request and response, including the path part of URL.

So out of this url: https://www.example.org/search.php?sdata=somedata
the following will be encrypted: /search.php?sdata=somedata
the first part, https://www.example.org, will NOT be encrypted (read more why not).

Whats not hidden, is the destination IP and destination port. Furthermore, the DNS request immediately preceding this, is sent in the clear.

A sniffer, can detect the caonical name of the destination in 2 ways:

Either, it can remember previous sniffed DNS responses, so if you previously did a DNS lookup for lets say api.example.org and got a IP of "8.8.4.4", the sniffer can then replace all occurences of 8.8.4.4 later with api.example.org

Or, it can do a so called rDNS or reverse DNS lookup. This means you do a lookup for a PTR record for the IP in reverse, so the rDNS of 8.8.4.4 can be found at a PTR for 4.4.8.8.in-addr.arpa which results in google-public-dns-b.google.com, thus the sniffer can replace all occurences of 8.8.4.4 with google-public-dns-b.google.com

Since you only can see the API destionation for some of the traffic, I suspect its the first case that is valid here, because if you did the DNS lookup prior to running the sniffer, this lookup is then cached for a period in your phone, which means that if the server in question lacks a rDNS value, the sniffer will normally display a IP instead of caonical name, which can give the apperance that some destinations are "encrypted" when they really are not.

If you want to hide the API destination from sniffing, you have to use some sort of proxy or VPN, where the traffic between the client and proxy/VPN is encrypted.


What can you tell about this form input when it gives internal error with ';--' and not ';--? I am doing a black-box test on a website. It has a form and i was testing it with different inputs. When i enter some specific inputs, it returns internal error.

Some inputs that give internal error:

';--'
';---'

Some inputs that doesn't give error:

';--
';-f-'
";--"
;--'

As you can see it's not a normal SQL injection flaw. If it was a normal SQL injection, results for ';-- and ';--' and ';-- ' should not differ.

If you have any insights in the way that this input is tested or the flaw that i am dealing with. Btw I can test more inputs if necessary.

From the samples given it appears to be a normal SQL injection with a string.

For argument sake, say the query was

select * from users where username='<user data>' ;

It is correct that the first two do cause an error as they produce invalid SQL:

select * from users where username='';--'' ;
select * from users where username='';---'' ;

Because with regards to MySQL comments:

  the “-- ” (double-dash) comment style requires the second dash to be
  followed by at least one whitespace or control character (such as a
  space, tab, newline, and so on)

Try ';-- '

Trailing single quote probably not needed.

The remaining produce either incomplete (i.e. no closing single quote) or valid SQL so don't produce any error:

select * from users where username='';--' ;
select * from users where username='";--"' ;
select * from users where username=';--'' ;

Note that

select * from users where username='';-f-'' ;

should error. I would confirm whether the result of this test case is correct.


Prevent Data Tampering I have developed a login page using php and i have an firefox addon named "Tamper Data 11.0.1.1-signed" . I entered the username and password and started tampering of that data using that addon. I am able to see the password in clear text in the data captured by the addon. Is there any way to prevent it? –

When a web page is displayed in your web browser a local copy of the webpage is stored in your computer. The web browser reads this local copy. You can in fact alter this local copy and it will not have any effect in the copies displayed by other visitors to that web page.

What the plug in is doing is something like that, it alters what you see or type in the local copy of that web page. One way is to display an overlay of the password, another is to change the type of the input from password to text, there may be others but they are all local to your computer.

You may choose to send that information back to the server (by submitting the form) or not, but before you send it (or an automated script does it), it has no effect on the server or in what other users are seeing on the website.


How do OTP USB sticks work? I just discovered the YubiKey NEO which seems like a pretty awesome device for maintaining security for a variety of different things including computer login, SSH private keys, GPG private keys, and even password safes applications.

I generally understand how systems like Google Authenticator work, wherein the server and the client share a private key which generates 6-digit number keys based on the current time. This makes sense, as both sides need to compute these values on the fly and verify them. The client generates a key, sends it to the server, and the server computes the key based on the current time; if it matches, a successful login occurs.

However, in other cases, notably in static files like private SSH keys, private GPG keys, and password safes, how would something like the YubiKey NEO assist in being able to unlock the private file? Encrypting these files using a passphrase or using a file as a seed for a passphrase is straightforward, but how would one-time passwords work with this?

My particular use-cases are:

Being able to log into my Linux desktop.
Being able to further secure my GPG private keys.
Being able to further secure my SSH private keys.
Being able to further secure my password safe (KeePass, Password Safe, etc.).

The YubiKey NEO is a unique One-Time Authentication device which combines the functionality of a YubiKey Hardware Authentication device with the extended capabilities of a smart card, without requiring additional drivers or software.

The YubiKey NEO has 3 major elements - the first is the YubiKey element, which allows the YubiKey to be used as a configurable hardware authentication device, capable of hold 2 independent configurations. Each configuration can be set to generate codes using the Yubico OTP, OATH-HOTP, a challenge-response configuration or a simple static password. All of the validation sever software used to support the YubiKey modes is also open source. In fact, a number of password managers have already integrated the YubiKey into their offerings - https://www.yubico.com/applications/password-management/consumer/

One of your use cases is the requirement to log into your Linux desktop. This can be simply done using the YubiKey and the Yubico - PAM module (https://developers.yubico.com/yubico-pam). The same Module can also be used to secure your SSH with second factor authentication as well (https://hak5.org/episodes/hak5-1114).

The second element of the YubiKey NEO is the secure element on the NEO which allows for smart card based functionality, including using the YubiKey NEO as a PIV compliant smart card for holding certificates (https://developers.yubico.com/yubico-piv-tool/doc/YubiKey-NEO-PIV-Introduction.html). Further, the YubiKey NEO has an OpenPGP applet, used to securely hold your private keys on the YubiKey itself, preventing them from being expose should your system become compromised (https://www.yubico.com/2012/12/yubikey-neo-openpgp).

Finally, the YubiKey NEO is the first device to support the revolutionary new protocol, U2F (https://fidoalliance.org/adoption/video/yubico-fido-alliance-universal-2nd-factor-u2f-demonstration). This next generation authentication protocol looks to provide the security of a smart-card based solution with the ease of integration and support of a traditional hardware authentication token system.


How to circumvent compromised CPUs in major FOSS operating systems As Matthew Green puts it, "the NSA has been ... Working with hardware ... vendors to weaken encryption and random number generators." At this stage, however, there is little public knowledge of which specific hardware products have been compromised by such efforts, and in which ways. That makes it difficult to know how to respond to such news, when making purchasing/deployment decisions, if one wishes to avoid using compromised functionality. (A rare case which is publicly "known" is the Dual_EC_DRBG random number generator used by various products, although apparently not by the RdRand instruction available on some Intel CPUs.)

For example, if it were the case that the AES or AES-NI functionality available in some Intel and AMD CPUs has been compromised, but the rest of the CPU behaves expectedly, then avoiding the compromised functionality would not necessitate avoiding those CPUs: it would be sufficient just to avoid using the relevant instructions.

My questions are:

Can that be done in the OpenBSD Cryptographic Framework (OpenBSD/FreeBSD/Illumos/etc) and in the Crypto API (Linux), and if so, how?
Given that:

suspect hardware is pointless in cryptographic applications, and
on-chip AES or AES-NI is pointless except in cryptographic applications,

do you think CPUs with AES or AES-NI are now pointless?
Have I got the wrong end of a stick here?

The AES instructions have to produce the proper output. If they were tampered with in a way that changed output, it would be detected very quickly, and there have been no reports of that. This limits the scope of tampering considerably (to side channels and such), and I can't see that being readily exploitable by the NSA.

A random number generator is a different beast. It's possible that while it looks to you and I like a random stream, it has some special property that the NSA can use to predict it. RdRand and Dual_EC_DRBG are both under suspicion.

So a practical step is to use additional random number generator instead of (or in addition to) RdRand. Most crypto libraries already do this, or can be configured to (more info)

That's probably the only reasonable countermeasure. In theory a backdoored CPU can do anything: leak your plaintext directly to the NSA, store your keys permanently on the chip, etc. But there's nothing you can really do about that.


loadbalancer, 2 webserver, 1 webserver hacked , how to tunnel out? Lets say I have one load balancer (HAProxy) and two web servers
one gets hacked. Is the attacker able to make outgoing connections when the web servers have no direct internet access (only ubuntu update servers) and connections to the load balancer?

How about a reverse proxy (nginx)? would this prevent outgoing direct connections? How could they spawn a shell? (I'd disable ICMP and DNS, and I'd check the integrity of the webapp files)

The short answer is YES  an attacker can still pop a shell despite these conditions.

Using iptables you can deny all incoming but tcp 80 and 443 for http and https respectively.   In addition you can deny all outgoing traffic (but you'd want to still allow for updates). But this can only do so much. You want to protect your web application and it would be more beneficial to use a Web Application Firewall (WAF) like mod_security.

In a web application platform you should be more worried about the owasp top 10 and web application exploits.  A major concern is that an attacker exploits your system and then installs a backdoor like the C99 shell.   In this case iptables doesn't mean anything, you have to allow http/https and that's all the attacker needs.

Blocking access with iptables does make the system more difficult to compromise with a buffer overflow.  For instance download+exec shellocde is very common because it's a straightforward attack where the victim downloads and executes a backdoor.    However the attacker doesn't need a connection to upload and execute a file.  By using an egg-hunter as staging a buffer overflow exploit then the attacker can include a fair amount of complexity in the payload.   For instance this would allow the attacker to load his executable in memory and then write it to a file.

The bottom line is Defense in Depth  and security in layers.  Use the most restrictive firewall rulesets you can.


Protecting WordPress from a single machine DoS (either in network/web level)? I use a DigitalOcean Ubuntu 16.04 machine with Bash, LEMP and WordPress.

I already did the best I can to protect the system and WordPress from BFAs and Backdoors, and to protect WordPress from DB injection by issuing only one simple contact form and automatic updates from the WP-CLI.

In all humbleness, it's unlikely that I'll be attacked in DDoS, but I do have a small fear of a single machine DoS (SMDoS) attack as many data requests from one machine.

The fear of an SMDoS woke up in my mind after thinking that I cannot know if someday I'll have a clash with some unstable person which happens to know Linux cracking well enough and will try to destroy a site / server environment I have I have as a revenge.

Gladly I didn't have to cope with such case but I do want to prepare myself for such unlikely case. SMDoS is indeed something just one human can do.

I don't know what's needed for the attacker to do that in the network level but in the web (application) layer I think nothing more is needed than some JavaScript.

A good defense against DDoS attacks (and smaller DOS attacks) is using cloudflare. They have a free tier for websites that offers an "I'm under attack!" mode. Read more about it Here.


How can I validate the authenticity of SSL certificates when Blue Coat is used? I work for a large corporation that uses Blue Coat as the proxy server. This causes the proxy server to intercept all SSL traffic, then reissues a new certificate to browser from the server itself.

The problem I'm facing is that whenever developer tools download resources via SSL, every certificate fails validation. I suspect this is caused by our Blue Coat proxy. The tools in question are pip (Python's package manager) and npm (Node's package manager). Lucky for me they both accept a client certificate in PEM format.

My current undesired solution is to disable SSL across the board.

What specifically do I need to ask from my IT department in order to validate third-party certificates in this instance?

PS C:\dev> pip install e -v
Collecting e
  Getting page https://pypi.python.org/simple/e/
  Starting new HTTPS connection (1): pypi.python.org
  Could not fetch URL https://pypi.python.org/simple/e/: connection error: [SSL: CERTIFICATE_VERIFY_FAILED] certific
verify failed (_ssl.c:600) - skipping
  1 location(s) to search for versions of e:
  * https://pypi.python.org/simple/e/
  Getting page https://pypi.python.org/simple/e/
  Starting new HTTPS connection (2): pypi.python.org
  Could not fetch URL https://pypi.python.org/simple/e/: connection error: [SSL: CERTIFICATE_VERIFY_FAILED] certific
verify failed (_ssl.c:600) - skipping
  Could not find a version that satisfies the requirement e (from versions: )
Cleaning up...
No matching distribution found for e
Exception information:
Traceback (most recent call last):
  File "c:\dev\pypi\lib\site-packages\pip\basecommand.py", line 211, in main
    status = self.run(options, args)
  File "c:\dev\pypi\lib\site-packages\pip\commands\install.py", line 305, in run
    wb.build(autobuilding=True)
  File "c:\dev\pypi\lib\site-packages\pip\wheel.py", line 705, in build
    self.requirement_set.prepare_files(self.finder)
  File "c:\dev\pypi\lib\site-packages\pip\req\req_set.py", line 334, in prepare_files
    functools.partial(self._prepare_file, finder))
  File "c:\dev\pypi\lib\site-packages\pip\req\req_set.py", line 321, in _walk_req_to_install
    more_reqs = handler(req_to_install)
  File "c:\dev\pypi\lib\site-packages\pip\req\req_set.py", line 461, in _prepare_file
    req_to_install.populate_link(finder, self.upgrade)
  File "c:\dev\pypi\lib\site-packages\pip\req\req_install.py", line 250, in populate_link
    self.link = finder.find_requirement(self, upgrade)
  File "c:\dev\pypi\lib\site-packages\pip\index.py", line 571, in find_requirement
    'No matching distribution found for %s' % req
pip.exceptions.DistributionNotFound: No matching distribution found for e

Bluecoat and other firewalls do SSL interception to analyze HTTPS traffic for malware too. To do this they create a HTTPS connection between the firewall and the server and a new HTTPS connection between the client and the firewall. Of course this new connection can not have the original certificate of the server, since the firewall does not have access to the private key of the server. This means that the firewall will create a new certificate signed by a CA at the firewall.

To validate this new certificate the client has to trust the proxy CA of the firewall. Usually this is done by adding this CA as trusted to all computers inside the company. But, different applications use different trust stores and this certificate is usually only added to the OS specific trust store, which means that in Windows only IE and Chrome will automatically trust the proxy CA. For any other applications you need to explicitly add the CA as trusted. How this is done depends on the application but for pip you might find help at this question.


Does escaping quotes in a HTML attribute context prevent XSS? I'm learning about XSS and I found I can inject code in this tag a few days ago.
Tag:
<div id="pagenotfound" title='Cannot find /it/search/testtesttesttetst\'onload=alert(1)'>

My payload:
/testtesttesttetst'onload=alert(1)

URL:
/it/search//testtesttesttetst'onload=alert(1)

I have locked < > " & % and many more characters (When I put ' automatically becomes this \' )(The last ' already comes with the page). So, is possible to inject any type of XSS payload in this website?

Yes, XSS is possible.
Escaping is not a proper defense against XSS in a HTML attribute value context because the HMTL parser doesn't care about escaping (it only cares about encoding).
When you have
, browsers will interpret foo as an attribute and bar as a value.
So why isn't your payload firing? Because onload is not a valid attribute for div. What will work is a payload such as test\'onmouseover=alert(1) :

test

In some browsers, you can also gain XSS without user interaction in a div, see eg here.


Filtering of port 3306 and opening only in times of need - The ultimate defence from DB hacking? (question had major update) I am not from the IS field and want to ask: Can we conclude that filtering of port 3306 and unfiltering only in times of need is the ultimate defense from DB hacking?

Let's assume I unfilter the port for 2-3 hours total in one year, just to make some DB changes (say, with Workbench, or in a bit less secured way, PHPmyadmin) and then filter it again for some long months.

In my case for example, I can't use an IP whitelist (mainly because of travelling restrictions), hence it seems as the best solution I have at the moment.

Can we say that as long as the port 3306 (or a substitute port) is filtered, I am fully protected from BFAs or from SQL injections on the DB (given the Firewall has no breaches) unless someone brakes into the PC itself and doing changed from there ?

Update - I seem to have had a flaw in the question:

The original phrasing of he question is above and some answer deal with it, but it seems I confused both the ongoing DB access via port 3306, with interntal access from PHPmyadmin (PMA), as well the issue of BFAs, with the issue of SQL injections.

I will emphasis the issue of BFA below:

I know see that even if I would filter the port with CSF and never unfilter it afterwards - Than from one hand, I would still be exposed to port knocking (which is a case by itself), and from the other hand, would still be able to use PMA from the URL, something that I could secure in either of the following 2 ways (or a combination of them):

Installing and uninstalling PMA each time anew, in an automatic way with a script that contains uninstall timeout, after 2 hours.
Logging in to PMA under https (tls).

tl;dr: Absolutely not.

It takes less than 3 hours for someone to completely destroy your Database. I'll say that again - your idea in its current form is a terrible practice, and is NOT a substitute for input sanitization

~~Even if you'd said "We'll put the DB behind a firewall and whitelist IPs, it might have been a better idea.~~ - I see you updated your post, and can't do this.

Here are a couple of reasons why I feel this is not viable:

Scenario: I'm a nasty person watching your network for any sort of weakness. I'm very, very patient.

What happens: You mention that you are unable to use an IP whitelist. This means that I can now attack your server in a multitude of ways and not worry about having to spoof my location. How would I do it?

Set up a script to scan your site every, say hour - just try to resolve /phpmyadmin and watch if it resolves. If it does, I begin my intelligent bruteforce. Not very clean and very noisy, but hey - it almost always works.
None of your current solutions will prevent me from actually breaking your site in daily operations - SQL injection isn't only performed on one page - it'll work anywhere in your site where you haven't bothered to sanitize your inputs and are calling or pushing data to your DB. I'll start methodically attacking each of these areas throughout the year.

This should give you a pretty good idea why this isn't viable.

2nd tl;dr: Don't do it.


Using the user's GUID-id as a salt for Rfc2898DeriveBytes I use the Rfc2898DeriveBytes for creating an AES key for protecting the user's data.
For the salt value I would like to use the user's id, which is a guid.

My understanding is, that the only drawback of using the user’s id would be, that it will get easier to crack keys which were previously built for this specific user, in case the attacker is in the posession of the database. But since the attacker has already cracked the current key, there is no need for cracking elder keys, therefore I don't see this as an issue.

Is it a problem to use the user’s id as a salt for the key derivation?

Guid type
As an additional information, the guid is a Windows Sequential Guid. Therefore it is not really random but quite unique.

Given that you say the GUID is sequentially assigned and sent in network traffic, no, it is not suitable for use as a salt. While it will still prevent the typical scenarios of "attacker wants to crack all your passwords, so they build a rainbow table that can be used to look up any hashed password" and "two users used the same password, and you can tell because their hashes match", it's still weaker than it should be.

In particular, it does not prevent the scenario of "attacker wants to crack a specific password, so they build a rainbow table using that user's (known) salt". Yes, the attacker still needs to get access to the user's password hash, which implies they'd have access to the salt anyhow, but normally that then begins a race between the site admin noticing the breach and the attacker managing to brute-force the slow hash (you did use an expensive hash function, right?). If the salt is known in advance, the attacker can perform the slow process of brute forcing the hashes (by building a rainbow table), and then instantly determine the password once the user's hash becomes known.


Can you construct a non-lossy steganographic filesystem Recently I've been having a look at some interesting stenographic filesystems such as RubberhoseFS and StegFS. As far as I can see (at least in the case of StegFS) infeasibility of determining how many keys are used and how much content is encrypted with different keys is achieved to the extent that it is as strong as the cryptographic primitives involved - it really is infeasible to determine the number of different files encrypted with different keys and how many keys even exist in the system. In other words one can plausibly deny that any other keys save the ones he/she provided were used*. However, there is one disadvantage - these systems (at least StegFS) tend to achieve this by become lossy filesystems. So the main question is - is it possible to implement a system with plausible denyability that is at least as strong as accepted cryptographic primitives (AES-CBC, SHA1-HMAC, e.t.c.) yet is not a lossy filesystem?

*) I'm not saying exist here, because technically they do exist. One can just 'decrypt' any file name (existent or non-existent) with any random key and you will end up with something.

is it possible to implement a system with plausible denyability that is at least as strong as accepted cryptographic primitives (AES-CBC, SHA1-HMAC, e.t.c.) yet is not a lossy filesystem?

Yes, in a way. TrueCrypt and it's successor VeraCrypt support hidden volumes. They work by embedding a hidden encrypted container inside an encrypted container. You can protect the "inner" or "hidden" volume from being partly overwritten if you have access to it. But see Mark's comment for a gotcha. There are more; the TrueCrypt manual explains some of them.

This goes for StegFS, too. StegFS is only lossy if you don't provide it with the passwords to all the security levels you're using.

So you can easily construct a steganographic filesystem which doesn't lose your files - but in order for the filesystem to not overwrite them, it needs to know where they are, and this can only be achieved if you tell it the necessary passwords/passphrases before starting to work on the file system.

Have your cake and eat it, too

This is from your question in the comments:

  Basically my biggest question was whether you can derive the place to store the file given the password, and somehow there would be a function that would allow you to find a free spot, yet would not reveal used spots

Again, if you provide the system with all the relevant passwords, this is easy. A very simple way to come up with stable disk storage locations based on passwords is by using hash functions - hash a password, or any other combination of identifiers, and get a stable number, which you can use as a pointer to a disk storage block.

If you DON'T want to provide all the relevant passwords, then it becomes much, much harder, and file system efficiency will suffer greatly.

First, you'll have to agree on an important point: The file system storage space is limited. If you have, say, 1 TB of space, and you have 1 GB of hidden files stored in it, then no matter how good the system is, if you write 1 TB of files to the disk, your hidden files will get overwritten. This is impossible to avoid.

But there may be methods to make sure that the files only start to get overwritten after you copied the first 999 GB to the disk.

Consider the following block allocation scheme:Whenever your file system requests a free storage block, a counter gets incremented and the counter determines which block to allocate. This means that you won't ever allocate a block that's already used as long as there still are free blocks on the disk. So you don't need to worry about overwriting hidden files as long as there is still free space on the disk.

The idea comes with a number of problems. For example, in the presented form, this doesn't work so good because you can immediately see how many blocks were allocated. Then you could count the number of blocks currently assigned to visible files and if that differed greatly from what you came up with, you could infer that there are lots of blocks assigned to hidden files. The other explanation would be that these were blocks of files you had deleted, but that's another problem with this system: There's no easy way to claim blocks of deleted files - if you want to reclaim the space of deleted files, you'd have to run special defragmenter software that reorganized all the data on disk.

There's another idea that might work a little bit better: You can have the block allocator for visible files allocate free blocks by allocating blocks 1, 3, 5, 7, 9, ..., and eventually coming back in reverse to claim the even blocks ..., 10, 8, 6, 4, 2.

Then you could have the allocator of the first hidden level allocate blocks starting at 2, 6, 10, 14, ...

Then you could have the allocator for the second hidden level allocate blocks starting at 4, 12, 20, ...

and so on. Each level L would provide 1/2^L of the total available space before starting to mess with data stored in other levels. Depending on how much data you stored on the various levels, level 1 could get away with storing more than 50% of data before starting to overwrite data in all the other levels.

(BTW: This would have a side effect: In this system, if you wanted or needed to, you could prove that there were no more hidden levels beyond the last one by storing twice the number of blocks that were actually assigned to it in it. This would overwrite the data of all the lower hidden levels. E.g. If you wanted to prove that there were no more hidden levels beyond the first hidden level on a 1 TB disk, you'd just have to store 500 GB of data in it, and if you used the file system without any hidden levels, you could store the full 1 TB)

But does plausible deniability work in real life?

I'm very sceptical about whether plausible deniability works in real life (generally, not just with TrueCrypt/VeraCrypt/StegFS).

I imagine two cases in which you might be forced to give up your encryption keys / passphrases:

You're legally obligated to give them up because law enforcement in your country has the right to request them, and a judge can hold you in contempt if you don't give them up
You're facing some criminal who is willing to torture the keys out of you.

In both cases, I fail to see how saying "there really aren't any hidden files on my computer besides the ones I showed you" makes a practical difference from "I don't remember the password for the encrypted file you see right here, but I remember it is last year's tax return statement."

Both law enforcement and the criminal probably won't believe you either way (there is a reason why they're talking to you! they expect you to have some specific documents they haven't found yet, after all), and they'll use whatever methods they have at their disposal to make you give up the key/passphrase. You're better off with law enforcement, of course, because the methods they can use are much more limited in civilized states.

Just think about what it tells an attacker about you if you use StegFS: It means you're trying to hide files. So how many files do you have to reveal before you can plausibly explain there is nothing more to reveal? This might actually work against you: You can't plausibly show that you've revealed all your hidden files, so a court in a country where the law allows for it might hold you in contempt indefinitely because you can't prove your innocence...

If you do live in a country where a court has to prove your guilt instead, then what would most likely happen is that the police confiscated all your drives and sent them to be analysed by a forensic unit to see if they could find a way around your denials. They probably wouldn't be discussing your steganographic file system with you in order to find out how plausible it was that you kept hidden data on it. So in that case, again, it wouldn't matter whether you used a steganographic file system or simply encrypted your data.

Plausible deniability through steganography is a nice idea, but I seriously doubt it works in practice. https://xkcd.com/538/ is somewhat related to this - the real world doesn't always conform to what we're imagining it to work like.


How does the hacker protect himself when using reverse_tcp? A reverse TCP is a connection that starts from the victim back to the attacker, which in fact opens the 'door' for the attacker to hack the target system.

This connection is being triggered normally by a malware that contains the attacker address or some other address, and when the victim starts that malware, it initializes a road for the attacker to enter.

My question is how the attacker spoofs his address and protect himself from being tracked. Are there some sites that provide any kind of back-end terminal to be used by the attacker, or are there other ways?

"Spoof" may be a poor term that will lead you down unhelpful paths.

You want to obfuscate your location. Dynamic DNS or pivoting off of another server that you have cracked are ways to put layers in between yourself and the target and not expose yourself directly.

So, the victim connects to a static address (Dyn DNS or static IP of another hacked server), and then the attacker connects to this intermediate layer with a changing IP (free wifi, large network with NAT like a school, etc.).


Permissions for configuration file for program run as root that must be modifiable by SFTP A shell script (myscript) will be run as root, by cron. It reads IP addresses from a configuration file, and updates iptables to whitelist those IPs for inbound connections.

myscript uses a regexp (regular expression) to parse the configuration file for IP addresses at the beginning of lines. There is no obvious risk of a buffer overflow or a privilege escalation, because anything that doesn't match the structure and length of an IP address is ignored.

For operational reasons, this configuration file must be updatable by a specific, trusted person whose only access is via SFTP from an old-fashioned GUI SFTP program that is incapable of authenticating to sudo. (Think CyberDuck, FileZilla, WinSCP.) This person should not do anything else on the machine. Clearly, they should log in via a non-root account. Let's call their account sftp-user.

If the configuration file had root:root as owner and group, as most GNU/Linux configuration files do, then AFAIK the only way for sftp-user to edit them would be if the sftp-user account had passwordless sudo privileges. This would be dangerous: it would give the account much more power than necessary. So, a less risky alternative is needed.

My question is: of the following, which is the least risky set of permissions for that configuration file to have, and why?

permissions  owner      group
----rw----   root       sftp-user
-rw-------   sftp-user  root
-rw-------   sftp-user  sftp-user

Edit in response to David's helpful answer: Yes, in normal circumstances, the permissions above are equivalent. Assuming the only member of the sftp-user group is sftp-user, then each of them allows read-write access only to sftp-user and to root. But what about extraordinary circumstances: does one of the configurations then pose less risk than the others? E.g. have there been cases of privilege escalation via file ownership alone, such that mixing a root owner and non-root group (or vice versa) is a bad idea?

Assuming the only member of the sftp-user group is sftp-user, all of the permissions you have listed would be equivalent.  The only users that would be able to read or write the file would be sftp-user and root.

I would personally choose to create a "role group" for this (perhaps fwadmins for firewall admins) in case you ever need to have more than one person with access to this.  Then I would set the permissions as 0660 with owner root and group fwadmins:

-rw-rw----   root     fwadmins

I suggest explicitly setting the permission bits for root as well.  Yes, root can still edit it either way, but it's just a little cleaner to be explicit about it.


iptables: plaintext password protection I'd like to find a way to block or restrict my access to the web-pages  where my password is sent as a plaintext on the internet.

Let's assume if I have the same password for all web-pages, is it possible to set this up with iptables? if so, how?

I am a very new Linux user. Thank you for your help.:)

The rule you would want is following:

iptables -A OUTPUT -s match --string "password" --dport 80 -p tcp -j DROP

A breakdown is as follows, append to your output chain anything going to port 80 using TCP that has the string "password" gets dropped.  This doesn't check for any sort of encrypted connection so if your password is sent plaintext outbound it'll drop the packet.


Protect a page from email collectors I'm creating a page where a customer can edit their order before they pay for it. The page will delete as soon as the order is paid for, but what's the best way to protect against email/phone number collecting bots? It needs to contain the email address and/or phone number. There is no way around that. (Shipping address also.)

Although the page will expire within minutes in most cases, I still want a customer to be safe if they choose to place an order now and pay for it several months later. (The nature of my business is that knowing what you would like to order may take a bit of effort and research, which a customer would not want to repeat if they decide to delay their order until they can afford to pay for it.)

Also, the site currently has no log on system. I will develop one eventually, but even once I do, I always want anonymous purchasing to be an option. A customer should be able to edit their order at any time from the link emailed to them without creating a username/password.

Before I had this concern, I was going to have it be www.domainexample.com?id=7, but any bot could check id=6 and id=5 to see if they've been shipped yet, and id=8 to see if there is a new order yet.

How can I provide a similar level of protection against email address theft that larger more professional sites like eBay would offer? (If that's even possible with anonymous purchasing. I hope it is.)

Anyone offering language-specific advice, I am coding in php/javascript/html. Though I'm sure I can look up the php equivalent of any suggestions offered.

Edit:

Important detail I forgot to mention. The target audience is old ladies that can barely use a computer at all. Any security feature that impacts the user experience could cost hundreds of dollars in missed sales as the website becomes too intimidating to use.

Before I had this concern, I was going to have it be www.domainexample.com?id=7, but any bot could check id=6 and id=5 to see if they've been shipped yet, and id=8 to see if there is a new order yet.

Generate a long, random ID. If you for instance generate a version 4 UUID it'll be unique and not guessable. Anyone with the URL can access it, but it's infeasible to guess the link.

The UUID is essentially the authentication in this case.