people abusing the information within my WHOIS, which if I remember is protected by international laws, or at least should be.

I'm pretty sure there's nothing at all to that effect. There are terms and conditions put in place by service provider companies, but at best people are bound by them as far as they are enforced. There is very little "international law"; there are treaties, which various countries incorporate (or not) into their national legislation, but I doubt there's any international treaty specifically for domain registration "whois" information.

  I am receiving phone calls, spam emails, and threats.

What makes you think the spam has anything to do with you having published contact details in whois? You're doing business online, wouldn't phone calls be fairly expected if you have a company? If you aren't using specifically crafted contact details that you use only in your domain registration, how do you know that whois information is even the culprit? Threats, now that's more serious.

  I do know that my information is public, but it should not be abused because of that?

It should not, but there's no technical way to prevent it from being. For example, VeriSign / Network Solutions whois includes the following "terms of use" in the whois output:

  By submitting a Whois query, you agree to abide by the following terms of use: You agree that you may use this Data only for lawful purposes and that under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; ...

This would seem to cover most of what you mention, but if no one enforces it, then there isn't a whole lot you can do about it. I'm pretty sure that text is mostly there to cover their rear, not really to meaningfully protect the customer.

  Is there a way to report the people who is abusing this information? Should I actually spend my money on the private registration, even though my information is being abused and most likely recorded on their computer? What is the best way to handle this abuse of my information?

If you are receiving threats, or are being harassed, you should contact your local law enforcement and provide them with any pertient information. As for spam, that's just par for the course on the Internet these days unfortunately; I recommend installing a good spam filter and training it well.


How is a service running at a specific port discovered and how to hide it?

How do port-scanners ... get so much detailed information about the service and the OS

Depends on the specific service. For SSH a simple TCP connection to the service is sufficient since the server will reply with this information, i.e.
 $ telnet some-openssh-server.example.com 22
 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1

Similar trivial are information to gain from HTTP since systems commonly announce these information. Of course servers might actually lie about their version and OS, in which case this lie will usually be accepted by the scanner.

How can I make it so that no information is revealed?

The best way is to prevent the scanning in the first way. This can be done by only accepting connections from specific IP addresses, by requiring some port knocking before the port gets opened or similar. One might also try to change the provided details in the server configuration. If this is possible and how it is done depends on the specific server software.


That's simply a Bash shell that is bind to port 1524/tcp. It will run everything sent to that port on  Bash and reply with the output. You don't need tools like Metasploit for that; a simple Netcat or Telnet will do.

Isn't it just amazing how a simple Google search can reveal the target of your homework is Metasploitable 2 (spoiler alert)!

  Bindshell Exploitation

  Metasploitable 2 comes with an open bindshell service running on port
  1524. We will be using Netcat to connect to it.


Gmail Account Password Compromised Twice In Two Weeks

The problem appears to be related to redirecting my mails to another e-mail of mine. Because I have many e-mails, instead of trying to check all of them, I redirected all of them to my main e-mail account through POP3. Gmail sees POP3 unsafe, even though it is the only way to do it. This also explains why IPs belong to Google.

There is still the question why it happens once in two weeks while mails are being checked many times a day, but it makes more sense than someone figuring out the password.


Is SipHash a secure alternative to HMAC-SHA256 for user authentication?

The newer, 128-bit output version of SipHash is conjecturally appropriate for this task; i.e., if SipHash is as strong as its authors intend (if!), then yes, you can use it for that task.

An analogous remark can be said of SHA-2, but the main issue here is one of subjective confidence; cryptographers haven't examined SipHash in nearly as much detail as SHA-2, so subjectively, we have fewer reasons to believe it is as strong as it's conjectured to be, compared to HMAC-SHA-2.

So HMAC-SHA-2 is the more prudent option here.  I would only consider using SipHash if I'd conclusively shown, based on profiling data, that SHA-2 was a significant performance bottleneck for my application.


Can I add 'user-identifying noise' to MP3 files to determine which user shared my file, if I find it later on the internet?

This method is called Audio Watermarking and it's around for a while. It's not as easy to use/implement as you think, and it's not very effective.

If you want to try, I can sugest two sites with some information on methods to watermark mp3 files.


How to stop other websites from sending cross domain AJAX requests?

As well as via a cross-domain AJAX request with credentials, the POST in your example could also be sent by using a standard form without AJAX:

<form method="post" action="http://MyApp/Page" name="hiddenFormInIframe">

<input type="hidden" name="my" value="a" />

</form>
<script type="text/javascript">
  document.hiddenFormInIframe.submit();
</script>

This would also include cookies in the request.

The vulnerability you are talking about is called Cross Site Request Forgery.

You can guard against the POST being submitted from another domain by sending a header in your AJAX request and then checking the header server side. A common header to use is X-Requested-With. This header cannot be sent cross-domain via AJAX due to this header not being in the safe list (without CORS being enabled on your server). A HTML form cannot send this header either.

Only the following headers are allowed cross domain via AJAX:

  Accept
  Accept-Language
  Content-Language
  Last-Event-ID
  Content-Type

The X-Requested-With header is automatically set when using JQuery and you can check for this in your ASP.NET code.

However in the past there have been some exploits via plugins such as Flash where headers could be set that were not possible via a browser (e.g. Referer) so to guard against this it is recommended to use the synchroniser token pattern which involves setting a token in a hidden field or in a header. This token will be validated as well as the authentication cookie for all requests with side-effects. That is, requests that change, submit or delete (normally POSTs).

For more info on CORS see here: http://www.html5rocks.com/en/tutorials/cors/


Secure algorithm for transferring data between users via QR Code

You are overcomplicating this. A counter of QR codes per day, daily salts, values that need to be synchronized...

I would simply design the application having an ECC keypair. When A wants to give N points, it makes a 'coin' with the information (timestamp, sourceUser, points, expiry), signed with its private key.

Then user B scans the coin and presents that to the server, «I am user B and want these points, here is the check signed by A». The server just needs to verify that

it has a valid signature from A
the last transaction by A was earlier than this coin timestamp (just a counter would do, too) - in order to avoid double spends (I am assuming that a valid transaction invalidates all previous ones that might be pending and somehow the server didn't see yet)
A actually has enough points to give out

Since A and B will be at the same place, the expiry an be as short as a few minutes, which is nicer than the daily salts (what if A is offline and meeting B after midnight?). You need to allow a bit of leeway for unsynchronized clocks between devices, but since the points would be redeemed almost instantaneously, at the point it starts being rejected it would be easy to understand by the end user, too when you tell them "This offer was only valid until XX:YY, it's now XX:ZZ, please check the clock time is set right."


Encrypting IP addresses in a MySQL database

Public / private key encryption is slow. It's ideal for write it & forget it, but it's not a fast process.

For the sake of speed, consider this: use a randomly generated symmetric key that is chosen when the daemon starts and possibly is rotated out every hourly, daily, weekly, or monthly (depending on your traffic and security needs). Leave that key in memory only and encrypt that symmetric key to a database table with the public key of your keypair. Then you can recover the key, but an attacker can't get it from except by dumping the processes memory. Even then, the attacker can only use the most recent key. You will likely want to use something to link the keys to the data or you'll have to brute-force your list of keys against each record. That recording could be as simple as start / stop time if your logs are timestamped, or sequence numbers, or starting encrypted entries with a key id field, etc.

Regardless of what method you use, pad your IP before encrypting it. I see that since you updated your answer this is mentioned, but it's definitely important for anybody referencing this. That will prevent indexing, but it will also prevent any "pigeonhole" issues and the same IP always having the same encrypted output.


What are the benefits of enabling antivirus full scanning?

It is extremely common for Anti Virus software to continuously update their scanning rules/parameters to allow the software to cast a wider net and detect the latest varieties of malware.

Usually, this update works hand-in-hand with the scheduled-full scan. Before a full scan happens, the software will check for updates then proceed to do the scan.

'Auto-Protect' basically just detects for malware with the current un-updated checklist. Hence with the full-scan + updates, it allows them to be sure that the latest malware is being hunted!


What does a Firewall mean by "connect to TCP port without your permission"?

Those messages get a D- for technical content and accuracy.  The most likely explanation is that these packets arrived late and failed the ESTABLISHED,RELATED check because the connection was already closed.

Somewhat less likely is that they actually had the CONNECT flag set in the TCP header, and your firewall is either dropping all incoming connections or the target port was closed.

Random incoming connections can occur due to malicious port scans, but also due to dynamic IP allocation giving you an address which was formerly allocated to a user of peer-to-peer/mesh transfer software, such that the address has been advertised in the mesh.  However since these are coming from sites that you do use, more likely is that the packet arrived after you already moved on to another webpage, and the browser was no longer listening for the data in question.

Unfortunately, describing the firewall action as a "block" is lacking in information as well.  There are two possible actions when an unwanted packet arrives -- DROP it, or respond with REJECT.  Rejection can take the form of an RST flag in a TCP return packet, or an ICMP "port unreachable" message.  Either way, explicit rejection leaks information about your network configuration.  At the same time, DROP can be caused by network congestion, so the remote end may retry.  So for your "friends" (legitimate communication partners), it is preferred to REJECT, while for random port scans it is definitely preferred to DROP.  And your firewall is not telling you which it is doing.


I believe your mixing several separated technologies together.
First BD-J => this is a special subset of "java" which is used for the menu's and interactive elements, it runs inside its own VM-container and does NOTHING on the host without the player software (so it works with the same permissions as your player or lower... meaning your user or none at all) source:Wikipedia article BD-J

BD+ is a a virtual machine embedded in players. it is NOT JAVA based at all. It can verify a players footprint against a list of allowed fingerprints (this does not really apply to PC's) and it facilitates the decryption of some "corrupted" data from a hidden secret encrypted location on the disc.

the way it can "run code" is through so called "TRAPS" this is hard to write code for, or even utilise for arbitrary code injection. all though not impossible.

The way for example VLC utilise DB+ is through running the VM in its own Library container it in no way runs with root permissions it just yieldds the enrypted blueray information for playback. source:Wikipedia article BD+


UK or EU regulations that require Security Awareness Training

I knew it had to be in DPA somewhere...while not an explicit reference to training/awareness, Data Protection Act 1998, Schedule 1, Part II, paragraph 10 states:

  The data controller must take reasonable steps to ensure the reliability of any employees of his who have access to the personal data.

By implication, for staff to perform their data protection obligations reliably they will need to be aware of what those obligations are and trained in how to meet them.


TL;DR: your "encryption" system is weak and will only hold as long as nobody interested in cracking it.

Remote systems on web only have access to list of names of your installed fonts through JavaScript, so you actual font file with glyphs is safe from generic attempts to obtain such a font.

However if you come under targeted attack, I can think of several options to get it. Easiest will be to choose your font for text in some graphical environment (DOM canvas, Flash), write big repertoire of characters with it and then submit bitmap snapshot of the surface to attacker's server.

BTW, I understand that you use a simply replace some alphabet letter-for-letter with your glyphs? Such a scheme is very weak and some people can involuntary crack it by just looking at it, so it is hardly recommended to encrypt any sensitive data, and according to your worries, it seems that data is indeed sensitive.


Clarification of PCI DSS 3.1 requirement 6+8

The idle timeout does not only apply to administrative accounts or internal accounts.  It applies to:

  all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used
  to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors and other third parties (for
  example, for support or maintenance).

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf


The HSTS header stops MitM attacks by instructing the browser to always send HTTPS (as opposed to HTTP) request to the domain until the policy expires. So a browser that respects the header would send a request to https://example.com even if the user clicked a link to http://example.com.

The logic behind HSTS has not changed since it was defined in an RFC in 2012. What has changed is that today almost all browsers implement it. Remember that it is the browser that enforce this policy! Can I Use reports browsers supporting it from the following versions:

Internet Explorer 11 (2015)
Firefox 4 (2011)
Chrome 3 (2010, possibly also supported earlier)
Safari 7 (2013)

(How Firefox and Chrome managed to support HSTS before the RFC was out is a mystery to me.)

So people using browsers older than that will not be protected even if the header is set. That might account for why you have the impression that setting the HSTS header did not use to help against SSLStrip earlier.

Another reason for HSTS not helping can be that the user has never visit the page before the attack. If the browser has never seen the header it can not enforce it. This can be solved with preloading.


There is no hack necessary to send mail with your mail address - anyone can send mails with any sender address to anyone, if the receiving mail server does not have stronger policies. (This is caused by the open structure of the Internet.)

A hack would be necessary to read your mail.

If you want to make sure that no one can send mails in your name, sign your mails (using PGP or S/MIME), and tell all your correspondents that they should discard any non-signed mail claiming to come from you.

Some analysis of the header lines.

The additional two Received lines do not add much.

Received: by 10.220.187.65 with SMTP id cv1cs37222vcb;
    Tue, 28 Jun 2011 12:25:05 -0700 (PDT)
Received: by 10.236.176.38 with SMTP id a26mr5411029yhm.410.1309289105028;
    Tue, 28 Jun 2011 12:25:05 -0700 (PDT)

These are private addresses, inside a local network, and they don't say from where they receivded the message. (These are the last stations that the message went through before arriving at your friend). If your friend used the Gmail web interface, these most likely are Gmail-internal servers.

Then we have these:

Return-Path: <MyEmailId@gmail.com>
Received: from ROCKY (host216-212-117-146.birch.net [216.212.117.146])
    by mx.google.com with ESMTP id l25si2327155yhm.109.2011.06.28.12.25.04;
    Tue, 28 Jun 2011 12:25:05 -0700 (PDT)

The return path shows what was mentioned in the SMTP dialogue as MAIL FROM. This was added by the receiving mail server, most likely the one in the next line: mx.google.com. This server got the mail from a SMTP client who identified itself in the SMTP dialogue as ROCKY, had the IP address 216.212.117.146 (which has a reverse DNS mapping to host216-212-117-146.birch.net).

This seems to be an IP address in the US (assigned by ARIN to Birch Telecom and from them to Premier Mortgage Funding. Either they have a bot-infected computer there, or they really sent the mail. (Or someone earlier in the list was spoofing the whole header.)

Do you know anyone at this location? Does the contents of the mail in any way relate to mortgage funding?

Received-SPF: neutral (google.com: 216.212.117.146 is neither permitted nor denied by domain of MyEmailId@gmail.com) client-ip=216.212.117.146;
Authentication-Results: mx.google.com; spf=neutral (google.com: 216.212.117.146 is neither permitted nor denied by domain of MyEmailId@gmail.com) smtp.mail=MyEmailId@gmail.com

These lines are added by the same server, most likely. The server did an SPF check on the mail address and sender's IP address, and has neither a positive nor negative result.

Google's SPF DNS records look like this (line breaks by me):

gmail.com.         259  IN   TXT     "v=spf1 redirect=_spf.google.com"

_spf.google.com.   236  IN   TXT     "v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19
                                             ip4:66.249.80.0/20 ip4:72.14.192.0/18
                                             ip4:209.85.128.0/17 ip4:66.102.0.0/20
                                             ip4:74.125.0.0/16 ip4:64.18.0.0/20
                                             ip4:207.126.144.0/20 ip4:173.194.0.0/16
                                             ?all"

Some IP ranges (which likely include GMail's web servers) are explicitely whitelisted, and the rest is mentioned as neutral by the ?all tag at the end.

If the mail were sent from GMails web interface (or via Gmails SMTP authenticated submission port), then there would likely be a "spf=positive" or similar result in the header instead.

Message-Id: <4e0a2a91.a5b5ec0a.0aa1.ffffdca7SMTPIN_ADDED@mx.google.com>

This message-Id is also added by the accepting mail server.

From: "MyFullName"  <MyEmailId@gmail.com>
To: MyFriend@gmail.com

(I suppose name and mail address were on one line.) Now it gets interesting. The sender knew your full name, as well as a fitting mail address. Do a Google search - is this combination public knowledge (i.e. findable on the web)? If not, then it is likely that either someone's address book got "hacked" (i.e. someone got some malware which is collecting these addresses), or some website where you entered these sold your data.

X-Priority: 1
 Priority: urgent
Importance: high

These header lines would give the mail a quite good chance to get stuck im my filter, I think :-)

Subject: Email from MyEmailId@gmail.com

This is also a typical spam subject line.

<Subject>

  I have not posted the Subject as it is personal.

Do I understand right, the text of the mail contains personal details, and not a generic spammy message?
Could this be some text copied from a mail you (or someone else) wrote before?

Other than this, it could be someone who knows you and your friend and who wants to play a prank to both of you.


How could ISPs "clean up their act" to protect against Mirai?

Blocking telnet to the routers. It should be blocked anyway as one of the most basic security configurations (hence the phrase, "cleaning up their act").

Telnet used to be the standard method to get shell access on remote computers. The only problem was that there was zero security in the protocol. Then ssh was created to do the same thing, but using secure channels.

SSH is such a common and standardised tool now that there should be no reason to ever need telnet. The fact that the routers are even designed to respond to telnet requests is surprising (and troubling).

If a device uses telnet, an ISP can protect the device by simply blocking traffic to it on the standard telnet port: 23.

I doubt ISPs would do it (too resource intensive), but one could also inspect traffic to the routers to look for the default password strings and block those packets. It's more of a technique for local networks than for ISPs, but it's another route for protection.

What makes this problem so big for these routers is that both the credentials and the telnet service are hardcoded into the firmware. You can't change it and can't turn it off. The only way to protect yourself is to block traffic to the device on the port it is configured to listen to (telnet port 23).


Security over multi-streaming such as SCTP

[...] my idea is to generate a random key and send it over stream 0 with info that it is for securing stream 1. But is this safe even when stream 0 is already secure?

You can do that legwork yourself, but I don't think you'll have to.

RFC 3436 says that you can do a full TLS handshake on the first stream and then an abbreviated handshake (using TLS session resumption with the session ID from the full handshake) on the other streams.

Would this work for you?

Further reading

There is a discussion of "TLS over SCTP" vs. "SCTP over IPSec" in this paper: JOURNAL OF COMPUTERS, VOL. 2, NO. 4, JUNE 2007, Secure End-to-End Transport Over SCTP


nmap's -sn flag works when a single target is specified, but, not when multiple targets are

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 purpose of HTTPS GET vs POST requests when certificate pinning?

GET requests can be forced upon you easily. Basically, suppose that there is a secure server to which you talk with GET requests under the protection of HTTPS and certificate pinning and whatever else you may imagine as some extra protection. Let's call www.example.com this server. Some of these requests are intended to have an effect, e.g. a GET request to:

https://www.example.com/sendEmail?to=foo@bar.com

triggers a process on your server which culminates in sending an email to the specified address.

Now, an industrious attacker follows you around and wait for you to sit down in some fast food restaurant with free WiFi; he knows that you will connect to that WiFi an engage into some casual Web browsing. The attacker whips out his own portable WiFi access points (like that one) and waits for you to connect to his hardware. At that point, the attacker can see and modify all your traffic. Of course, SSL keeps him out. However, when casually browsing, you don't visit only HTTPS Web site. If your browser ever makes a connection to an HTTP Web site (without SSL), then the attacker just has to insert the following text in the returned HTML:

<img src="https://www.example.come/sendEmail?to=francisco@vatican.va" />

and boom! You've just spammed the Pope. Indeed, upon seeing that small piece of HTML, your browser dutifully sends a GET request to the specified address. This works regardless of the provenance of the page in which this HTML tag appears; the GET requests from <img> tags totally evade the Same-Origin Policy.

POST requests cannot be fabricated that way. Therefore, regardless of how sure you are that you talk to the servers you intend, you shall use GET requests for read-only processing only.


Phishing/Malware redirection through AdExchange on Android

The term you are looking for is "malvertising", or malicious code sent via ad networks.

If the mobile app you used had a known weakness in the code (common libraries) that the malicious code tried to exploit, it is entirely possible that it could launch a browser session.


Password hashes are, in and of themselves, not part of FIPS 140-2.

To try to answer anyway, that depends - do you just need to use FIPS 140-2 algorithms?  For hashing, that's SHA-1 and the SHA-2 family.  For a random number generator, FIPS 140-2 doesn't apply - those are in completely separate NIST special publications.

RFC2898DeriveBytes is PBKDF2-HMAC-SHA-1; there are also nonvalidated C# example of PBKDF2-HMAC-SHA-256/384/512 by @JimmiTh at my GitHub collection, if you'd like to use those as well.

If you actually need to use FIPS 140-2 validated solutions, first you need to know what level validation you need (level 1, 2, 3 or 4), and then you need to find solutions that were validated by NIST at that level.

In both cases, you need to dive into precisely what "password hashing" means in the context of FIPS 140-2, since "password hashing" itself isn't part of FIPS 140-2.  Get legal or regulatory advice on exactly how you're allowed to use the algorithms FIPS 140-2 details; PBKDF2-HMAC-SHA-xxx is probably allowed, but make certain.

It's possible that your organization's interpretation of the letter of whatever regulations are pointing them at FIPS 140-2 contradicts normal best practices.  Once you're referring to any national government's standards, you need to know much more about the requirements.


Can Skype chat be protected from snooping? Are there safe alternatives?

There have been several suggestions that skype is indeed backdoored and evesdroppable. If your concerned about it because Microsoft is now the owner, there are plenty of other alternatives to Skype which I would suggest as the easiest and cleanest solution (besides, if MS is your competitor, why would you buy their services). Some of the alternatives like Jitsi document their security quite well and are open source which lets you check if they're doing anything sus.

To answer your question about the chat. I came across this guide which is a plugin for pidgin that allows for encrypted chat messaging and Skype functionality, but I don't think it improves the security of the calls made. The other party will obviously need the plugins installed as well but if your serious about improving the security then it should be worth while.

As a side note, @TildalWave pointed out in the chat Microsoft brags about an independent Skype security review however the paper they brag about is dated 2005 from before Microsoft bought Skype and before they implemented changes to encryption protocol from peer-to-peer key distribution to centralized public key distribution.


The Access Key ID is used for identifying the access key in logs, configuration, etc. It could in some environments be considered sensitive data if you're looking to not release who accesses which systems and when, but it is not secret.


What is the relation between "signature_algorithms" handshake extension and TLS ciphersuite

... since the ciphersuite already indicates both hash and signature algorithms

The hash given ciphersuite only defines the algorithms used for the integrity protection of the encrypted traffic, i.e. the HMAC. These are not for digital signatures. Similar the public key algorithm in the cipher suite is only about the public key of the server certificate used for authentication. It is not about public key of the client certificate nor about signatures used for the certificates.


best way to encrypt code and data on IOT device?

If you're ok encrypting the entire filesystem then I'd recommend using LUKS to encrypt the disk. It may be a bit more difficult to set up at first but provides a really nice solution.

Offensive Security does a beautiful job describing the (somewhat lengthy) process:

https://www.offensive-security.com/kali-linux/raspberry-pi-luks-disk-encryption/

They use Kali Linux, but that's not necessary. Just use a different Raspberry PI OS image in place of that.

The high-level steps:

Download the OS image and copy to an SD card
chroot to the image and install/update several files to prep for crypted boot
Create an initramfs file which includes Dropbear and freshly generated SSH keys
rsync the modified rootfs to a temporary backup location and then delete the rootfs partition from the SD.
Recreate an encrypted partition to restore the root partition data

Good luck!


Protection against Android Reverse Engineering

So you can still reverse engineer the .so binary to attempt to learn more about the algorithm and see if you can forge validation tokens. See the below softwares:

https://ghidra-sre.org

https://www.hex-rays.com/products/ida/

Both are very strong pieces of decompilation software, able to convert machine code (ASM) into human readable C++ for reverse engineering. It increases the difficulty of RE, but it's not impossible.

As for how they did that? Code signing can be used to verify the integrity of the code before execution. But all a .so is is a Linux shared object that was compiled from C/C++ code. So if you want to make it difficult for attackers to learn more about your model, you can if you so choose, write the algorithm in C++ and then link it as a shared object to the app, and then import/use its functions in your android project. That will provide a layer of abstraction between the app and the validation algorithm.


Drivers license required for online purchases

I'll start with the TLDR; version of the answers to your explicit questions, and then give some breakdown beyond that.

A merchant may set any requirement they wish upon a transaction (as long as it doesn't violate some other law).  They can ask for gov't issued photo ID, they can ask specifically for a RealID or Passport, they can even ask for a blood sample (gross, but allowable).  Of course, you can also set a requirement for working with a merchant (just say no and go else where), so their demands should have some balance to them.
Now, here is the trick.  Even if the credit card company isn't requiring it, the data they are asking for it Personally Identifiable Information (PII) and will be handled by a merchant that is doing credit card transactions.  The credit card industry requires that all this information be protected as part of PCI/DSS (Payment Card Industry Data Security Standards) even if it wasn't collected for card processing.  So once they have your license (PII) they have to protect it the same way they do credit card numbers and billing address.
See #1 -- a merchant can set any requirements they wish upon a transaction.

You can stop here and be ok, but I like more detail in my answers.  So, now, for the more interesting tidbits.

First, on the security side.  As someone who has worked quite a bit with online card acceptance I'll have to ask you to take my word for it: the detection system "trip points" you describe are all very valid and things I'd use in my own acceptance criteria.  Knowing that a purchase is coming from a known VPN (anonomizer) endpoint is a big red flag; sure it could be someone just wanting privacy, but it could also be a hacker using the data they just stole from that next data breach.  Followed up with the IP of the endpoint is physically distant from the shipping address (another common fraud indicator) and it looks just the same as someone stealing credit cards and drop-shipping goods to a pickup point.  It isn't, it's just you; but the pattern the automated detection system sees doesn't know the difference, or you -- hence point 3.  Having your email in their system means they've verified you before, they know that this is how you shop, and they are willing to accept that fact.  You didn't fail because you weren't a known account, it was just that they couldn't give you the "yeah, I already know this guy" exception.

Now, on to the questions on the purchase itself.  A transaction of purchase is a negotiated deal between two parties, the seller (merchant/store/whatever) and the buyer (you).  To complete a transaction either you both have to agree to each other's terms, or one (or both) of you will need to modify expectations/terms to make the overall deal an agreeable one.  As I mentioned above, a merchant may require a copy of my passport before they sell me something.  That's fine.  But I still have the option of saying "nope, I'll go over to Brownell's and just pay the extra $80 to not have to show that."  Either of you can negotiate the terms of the deal, it is only a purchase when both sides agree and fulfill those terms.

Again, terms within the bounds of the law.  Neither party may make any agreement term that directly contradicts the established edict of law: for example the merchant cannot make terms that discriminate based upon protected status (ie: the deal is no good if you are of a specific ethnicity

But this is a continuation for the merchant, they could literally be stuck in the middle.  To examine that let's play a bit of make believe.

So, let's imagine that your local mom & pop toy store (Johnny Doe's) has been running in the same place for a few generations.  They've got near-zero overhead, the building and land are paid for & they buy their stock up front; which in turn means that I can go shopping for something from my favorite Austrian or Belgian toy makers for about 18% less than I can get it anywhere else.  I like shopping at JD's, it saves me a lot of money.  And, about 12 years back they started taking "plastic" for payments, which means I don't have to go to the bank before buying one of the bigger toys...

Now, a couple of months ago JD's credit card processor (not Visa or MasterCard, not even the Merchant Bank that JD's uses, but the middle-man that handles the electronic connections of the credit/debit card scanner) decided that they didn't much like the kind of toys that JD's sold.  The processor upped their fees for verifying card transactions from 2% to 6% to try and "discourage" the use of their service at JD's.  Because of their contract, they can't dump JD's as a client, but they can change rates and requirements at will (and JD's signed up for that when they agreed to the contract).  To keep their margins the same, JD's adjusted the price of the toys by adding a fee "for the convenience of using card payments" (or, to stay within the terms of the agreements with Visa/Master/etc, they actually upped all their prices and give discounts for cash customers).  That's fine, in fact I'd expect it and I happily paid the higher rate because JD's whole shop was still cheaper than anyone else.  The card processing company modified the terms of the agreement with JD, who in turn modified the terms they put onto any sale (everyone raised their prices).

But this can very easily continue.  The card processor can now say "because we deem this class of product to posses a health and safety concern, we require that all transactions have additional supporting documentation to help verify that at-risk groups are not making the purchases" (aka: we need a photo ID for proof of age -- or address).  This is the same thing that most stores do with superglue and spray paint, "oh, you want to buy this, first let me see your ID to prove you're old enough to be responsible with it."  As a society we've grown accustomed to that and accept it; but you could just as easily tell the WalMart cashier "you know what I don't have it on me, just keep it and I'll go over to Ace where they make silly requirements."  That is, you can decline the terms and not make the purchase.

In the case of JD's toy store, they were stuck in the middle.  The card processor required something of them, and JD's didn't have enough leverage to negotiate a better deal (they're a small mom & pop, they have good volume for what they do, but not enough to change the mind of a company that keeps McDonald's and Target sized clients).  So when I try to negotiate a better deal JD's is stuck, they can either eat the expense (and watch profitability disappear, the most likely desire of the card processor) or they can pivot the deal (we can't lower the price, but we can give you a discount for cash).  In the end, old man JD himself still makes sure to keep a couple of boxes of consumables for my favorite Belgian toy on the shelf and I visit his shop regularly...


Security risk with using internal IP on public DNS

There is another risk using private / LAN IP addresses for public DNS records.

Suppose you have a laptop user in your LAN, who uses web.company.com (which resolves for example to 192.168.178.10).

If this user connects his laptop to another network (wifi!), and tries to use web.company.com, it will resolve to 192.168.178.1 using the public DNS entry. It may be possible that the IP address 192.168.178.10 corresponds to a machine on this foreign network. The laptop will then send information to this machine, which may even include plain text credentials, cookies or other data.

It may even be possible to setup a sort of honeypot using some detailed knowledge of the LAN.


What's going on with this URL? Has the honda website been hacked?

That's Honda's domain, right?

Yes it is. Either one of their web servers or their DNS has been compromised.

  Is this part of a blackhat SEO network or something?

Most-definitely. A domain for a large company linking to other websites raises their page rank.

Of course, it's possible the compromised web server is also up to other nefarious things.


Are variable time comparisons always a security risk in cryptography code?

No, they are not always a risk, and indeed, it is impossible to build a practical cryptographic library where every function is constant time.

Take, for instance, a decryption function. In a real-world cryptographic library, it is going to be faster to decrypt a 10 byte message than a 10 gigabyte message.  You could theoretically create a library where decryption was constant time for any message of supported size, but that would be absurd, so you have a variable time function that leaks (useless) information about the size of the message being decrypted. One of the specific reasons that this isn't an issue is the assumption that the attacker may have information about the message size is built into the security proofs.  Security properties are generally designed to only assume security for messages of a specific size, and since they don't apply to messages of different sizes, there is no impact to the designed security of a system if message size affects function completion timing.

In other cases, timing may be potentially sensitive, but a function may be designed to eliminate any information an attacker could use against the function.  Double-MAC'ing is one example of this.   Evaluation of a MAC is very definitely a function that is sensitive to timing attacks.  In an (for example) encrypt then MAC scheme, you compare a MAC sent with a ciphertext with a MAC freshly computed against the ciphertext, a timing attack could allow an adversary to repeated submit modified ciphertext/MAC combinations and iteratively compute a valid MAC without knowing the correct secret key.  If, however, on every comparison you re-MAC the MAC with an ephemeral key and re-compare, it doesn't matter if there are timing issues.  The ephemeral key in the second MAC will prevent an adversary from being able to iteratively produce a correct MAC because the new ephemeral key produced for each subsequent evaluation will thwart the effort to discover valid bits.


Given the sparsity of details, the SIZE of the company affected, and the fact that they were hit with a $1,000,000 ransom, my guess is that this was a targeted job that required a bit of recon beforehand to discover that they were using an ancient kernel, ancient webserver, and generally hadn't patched anything in a decade.

I expect a remote root exploit was used and coded in along with some tailored version of Erebus to encrypt the files.

I don't think this is a scenario that would necessarily be EASY to replicate. But it COULD be replicated if someone has a system with holes.

Given the target's overall lackadaisical approach to updating and security, we don't know what other kinds of security holes were available for the ramsomware coders to take advantage of.


PDF in browsers

Assuming the browser makes things safe for you, you shouldn't have anything to do on your end (more or less). Unless you are yourself implementing a browser.

One thing I've seen, though, are processors that will remove scripts from such file formats (especially in MS-Word/Execl files). Then you know that at least they won't execute anything on the client's machine. Of course, as a result the file may not display as expected by the author.
other formats

On the Internet, I'd just use HTML. However, if your clients need printing your data, it's better to have a PDF file (as it is more likely to appear as expected on the printer).

Otherwise, pretty much all file formats may include a script. Maybe RTF is limited in that arena, but I've not checked that format in ages.
PDF validation

For sure, you should make sure that the file is a PDF file, if not so, it can be refused. For that test, make sure you use a mechanism similar to what the file command line does:

file <your-file>.pdf

Just checking that a file has a given extension (.pdf) would not help one bit.

The best technique is for the server to read the entire file. Maybe run it through a PDF parser which spits out the text in a .txt file. If that works, then you can assume the file is a PDF and not some other random format.


Do some IoT devices connect to your wifi without you knowing it?

The owner normally has to manually configure the device to connect to their wifi, since (a) the IoT device can't automatically figure out which wireless network belongs to the device's owner, and (b) even if it did, it can't connect unless it can figure out the password.
MechMK1 mentions the possibility of the device connecting automatically to open Wifi Access Points. Although this is possible, its unlikely for an IoT device to be configured to do so, since as MechMK1 mentions, this would probably be illegal.

are those of any security concern besides possibly becoming part of a botnet?

Of course. There is a lot an attacker could do after compromising an IoT device, depending on the devices capabilities. For example, if you have a home security system connected to the internet, the hacker could use any security cameras to spy on you. Or the consequences could possibly be more lethal. For example, a hacked internet connected smart oven could perhaps be used to start a fire.


Are there more modern password hashing methods than bcrypt and scrypt?

In cryptography, "new" is not synonymous to "good". That bcrypt is twelve years old (12 years... is that really "old" ?) just means that it sustained 12 years of public exposure and wide usage without being broken, so it must be quite robust. By definition, a "newer" method cannot boast as much. As a cryptographer, I would say that 12 years old is just about the right age, and anything younger than, say, 5 years, is definitely "too young" for general deployment (of course, these estimates depend on how much exposure the algorithm got; an early, wide deployment, although risky for those who decide to deploy, will go a long way toward building confidence in security -- or revealing weaknesses at an early stage).

Scrypt is much newer than bcrypt; it dates from 2009. The idea is quite smart. Namely, slow password processing is meant to make dictionary attacks N times more expensive for the attacker, while implying that normal processing is N' times more expensive for the honest systems. Ideally, N = N'; the scrypt author argues that with PBKDF2 or bcrypt, use of ASIC allow an attacker to get a N much lower than N' (in other words, the attacker can use specialized hardware, because he is interested only in breaking a password, and thus hashes many more passwords per second and per spent dollar than the honest system). To fix that, scrypt relies on an algorithm which requires quite some RAM, since fast access RAM is the specialty of the PC, and a sore point of ASIC design. To which extent scrypt is successful in that area remains to be measured; 2009 is recent times, and the figures given by the scrypt author are based on 130 nm ASIC technology and an hypothesis of "5 seconds worth of processing", which is quite beyond what the average user is ready to wait.

For practical usage now, I recommend bcrypt.

Scrypt notwithstanding, current research on the concept of password processing is more about specialized transforms that allow more than mere password verification. For instance, the SRP protocol allows for a cryptographic key agreement with mutual password-based authentication, and resilient to dictionary attacks (even in the case of an attacker actively impersonating the client or the server); this calls for a bit of mathematical structure, and the password-hashing in SRP involves modular exponentiation.


Is there any security value of creatively naming folders containing sensitive files?

In security, attacks are generally divided into two categories: Opportunist attacks and targeted attacks. The former are generally low-effort and low intelligence (ie, no specific information or recon on the target), the latter have to be assumed to be motivated, well-equipped, and intelligent.

The broader issue behind this question is: Does obscurity do anything to thwart attacks by either attacker?

In short, "yes", because it does offer some resistance against opportunist attackers. Attackers aren't perfect and the defender can use to their advantage by capitalizing on the attacker's laziness or ignorance. Attacks by opportunists are modeled as being generally both ignorant and lazy. Opportunist examples:

People who steal a mobile device. Someone who steals the computer (if it is a mobile device) may not look through all the files, there are stories of devices that get stolen and the contents completely ignored.
Botnets. Malware is written to work on many machines. It is unlikely to upload every single file in a user's profile directory and also unlikely to be able to recognize an image of a signature.

For such attackers, Desktop/a_copy_of_my_signature.jpg is far more likely to be carefully processed than data/misc/receipts/DATA_1/rozs/ewa34.dat.

In this case, obfuscation here improves the odds of the signature file not being discovered but it doesn't really do anything to thwart a qualified attacker, so the security gain is minimal. So it's not ridiculous to take this measure, but it is silly to rely solely on it.

More generally, obfuscation can offer a worthwhile outer layer of security in a multi-layered security system. Remember that, as the defender, you win every security battle you prevent. (But don't become too reliant on avoiding them.)

On a side note, signatures aren't that extremely important to protect. Signatures exist in so many places and this person may very well have unprotected copies of it elsewhere in his house on various documents. (Or think about celebrities whose autograph signature matches their legal signature.) And just about any system that requires a signature has mechanisms in place to deal with fraud, so most forged signatures can be contested since this is a well-worn legal path. The signature is probably worth protecting, but it's also likely that the computer is not the easiest way to get a hold of the signature should he be the target of a determined forgery attempt.


Should we prevent access to non-sensitive information?

Don't prevent access. Don't make things hard for your team. Don't introduce gratuitous complexity, it is the enemy of security, and a sure path to technical debt. Don't look to obfuscation, to an attacker that is a clear sign that more obvious defenses have been overlooked.


Is a padding oracle attack possible with randomly generated keys?

If I understand your scheme correctly, it's this:

Client generates a random AES key and initialisation vector (IV).
Client encrypts that key with the RSA public key of your server, which it already possesses.
Client pads the message with PKCS#5 and encrypts it with AES-CBC using the IV + key they generated.
Client concatenates IV + encrypted key + ciphertext and sends it to the server.
Server receives the packet and splits it back out into IV + encrypted key + ciphertext.
Server decrypts the encrypted key using its RSA private key, but returns no error message if this fails.
Server uses the IV and decrypted key to decrypt the ciphertext, again using AES-CBC.
Server validates the PKCS#5 padding of the decryption and discards the message if the padding is not correct. No error is returned to the client.

If so, there are a number of problems here, mostly relating to malleability:

An attacker can pick a tweak T and replace the IV with IV ⊕ T, resulting in the first block of decrypted plaintext becoming M0 ⊕ T. This can be used along with known plaintext in order to spoof message contents.
An attacker can pick a tweak T and replace any ciphertext block Cn with it, resulting in Mn becoming corrupted and Mn+1 becoming Mn+1 ⊕ T. If an attacker knows that the data in Mn is not validated or not important for the purposes of the attack scenario, this can be used to spoof message contents via a known plaintext.
Even if you send back no error messages, there may be timing differences in your code that allow an attacker to distinguish (within a reasonable probability bound) between valid and invalid padding. This could be exploited in order to recover the plaintext of packets.

I recommend that you modify your scheme to the following:

Client generates a pair of random keys Ke and Km plus a random initialisation vector (IV).
Client concatenates Ke and Km together to make a combined key K.
Client encrypts K with the RSA public key to create the encrypted combined key K'.
Client pads and encrypts the plaintext message M with PKCS#5 and AES-CBC using Ke and the IV, resulting in ciphertext C, i.e. C = E(M, IV, Ke)
Client concatenates IV and K' and C to create an encrypted packet P.
Client computes H(P, Km) where H is a HMAC function, e.g. HMAC-SHA256, resulting in an authenticity record A.
Client concatenates P and A and sends this to the server.
Server extracts P and A from the packet.
Server splits P back into IV, K', and C.
Server decrypts K' with its RSA private key. If this step fails, the message is discarded. If not, the server now has the combined key K.
Server extracts Ke and Km from K.
Server validates that H(P, Km) == A. If this step fails, the message is discarded.
Server decrypts C using Ke and IV, i.e. M = D(C, IV, Ke), and validates the PKCS#5 padding. If the padding is invalid, the server discards the message.

The addition of an authenticity record ensures that an attacker cannot capture a message from the client, modify it, and re-send it to exploit a malleability attack or padding oracle issue. The idea is that an attacker could replace K' with their own value in order to know Km and forge messages, but in the process they'd also have to replace Ke which would result in invalid padding or completely garbled plaintext.


Does preventing buffer overflow attacks prevent ROP attacks?

A quick Google search says "no". The original paper from the original presentation (Section 4.2) says that although Buffer Overflow is easiest, it is not necessary.

  However, a stack overflow isn’t necessary. The payload containing the
  return-oriented program could be on the heap, and the attacker could
  trigger its execution by overwriting a function pointer with the
  address of a code snippet that sets %esp to the address of the first
  gadget and executes a return.


Is it secure to be using LDAP, or is LDAPS the only secure option?

LDAP, by itself, is not secure against active or passive attackers:

Data travels "as is", without encryption, so it can be spied upon by passive attackers.
Active attackers can manipulate the stream and inject their own requests or modify the responses to yours.

At best, basic LDAP may rely on some authentication mechanism (through SASL) which is not trivially broken by an attacker: if the authentication is of the "show the password" type, then a passive eavesdropper can learn the password and then connect to the server with your identity; slightly more advance protocols, like CRAM-MD5, avoid that specific problem, but will still do nothing against attackers hijacking your connections or spying on your actual requests and responses.

So, really, if you value your security, then use SSL (i.e. "LDAPS"). In many respects, this is just like HTTP vs HTTPS.

As a side note, the Active Directory protocol from Microsoft, which builds up on LDAP, optionally offers a "sign & encrypt" feature, which appears to be some sort of cryptographic protocol embedded within LDAP (i.e. like LDAPS, but in reverse order), which might ensure enough security. I have not seen any decently detailed specification for that protocol, though, so I still recommend LDAPS in that case.


IT will only give password over phone - but is that really more secure than email?

Emails are saved somewhere, whether it be on a mail server or someone's personal computer. Phone calls usually are not, unless it's a customer facing environment.


Can speculative execution on intel cpu be disabled?

No, it's not possible. Supporting a feature like that would require major changes to the microarchtiecture. Also disabling speculative execution is not the right approach so solve the problem. Speculative execution is so critical for performance, but it can be performed more securely, which is what likely will happen in successor microarchtiectures.


The easiest way would be using several databases. Tools like KeePass allow you to store passwords in different files. You could for instance opt to store your passwords in seperate databases based on client or purpose.


Are hashes a reliable method of ensuring a file has not been tampered with?

Yes! This is absolutely a valid method of ensuring files have not been tampered with.

For some background, cryptography as a field provides a handful of useful services when applied. The low-level details of what these are changes depending on who you ask, but they all center around 4 key things:

Confidentiality (so only the correct parties can view the data)
Authentication (so we know who the correct parties are)
Non-repudiation (so the correct parties can't say they didn't do it)
Integrity (so the correct parties get the correct data)

Sometimes availability (making it so the data can be accessed whenever it's needed) is also included in there. (Here's a Microsoft reference on cryptographic services for the curious.)

Different types of cryptography provide different levels of service. Asymmetric key cryptography provides all of them: using (secure) asymmetric key cryptography, only the known correct parties can get the correct data and can't say they didn't make the data. If you don't have the key, you can't get the data, and you can't the key unless you're the correct party.

Hashing is an interesting case, where it's extremely valuable as a concept and a practice but is very limited in what it can do. Of the 4 cryptographic services, hashing only provides integrity. It provides nothing by way of confidentiality, authentication, or non-repudiation, but cryptographically secure hashing is a fantastic way of ensuring that everything about 2 pieces of content are exactly identical. In fact, in some ways that's the only thing hashing can do.


How does malware install itself as a service without requiring user's credential?

Malware often comes piggy-bagging on installers for other software. When the user starts the installer of a piece of software they believe to be legitimate, they expect to be prompted for granting admin rights. The installer will then use these admin rights to install both the legitimate program and the malware.

This can easily happen when you obtain software from questionable or illegal sources.

A hypothetical method I never heard about in practice but which would be possible in theory could be a malware which waits for the user to download any form of installer and then modifies that installer to also permanently install the malware. This would require that the user downloads a software installer during the same session where they got infected with a malware in user-space, so I don't think this propagation method would be very effective.


found a very suspicious Apache log - is someone trying to hack?

Is someone trying to hack?

Your system has already been compromised because multiple POST requests were successful and all those unauthorized files have appeared in your folder/s.

From the information provided, I would assume that the gallery on your system has holes in it that allow uploading .php files which can be used for arbitrary code execution.

What you could do to confirm this is to look for the point of entry in the logs. Look for the first POST request which added a suspicious file on your system. Furthermore, you could track down all these unwanted files and delete them afterwards but to be 100% sure that the infection is gone, you may want to completely wipe and reinstall the system.

Now, this doesn't quite fix the problem as the exploit remains in your current WP version so consider updating to the latest version.


Why these 2 regexp won't work as expected in ModSecurity?

SecRule REQUEST_URI "^/(|(.*)/)(lpt1|lpt2|lpt3|lpt4)(/|\.|\?|$)" "t:none,t:htmlEntityDecode,t:lowercase,t:removeWhitespace,block,msg:'X',id:'1000'

There can be two problems with these rules.

HTTP request Transformation functions i.e t:htmlEntityDecode,t:lowercase,t:removeWhitespace should be in compliance with actual encoding scheme used in HTTP request. Modsecurity transform the input and apply the regular expression for each transformation.
You are using block as a disruptive action, problem with block that it uses SecDefaultAction value that can be pass, deny,drop. Therefore block may not be blocking the malicious HTTP request and replacing block with deny may solve the problem.


Is an asterisk in sudo command specifications safe?

Different applications have a different understanding of what the asterisk means. Shells tend to treat it for parameter expansion, which can be quite complex in implementation and often results in security issues when used in scripts. Sudo, on the other hand, treats it simply as a catch-all wildcard for any further parameters in that single command. In other words, it allows the service command to run with any arguments that match the following regex:

^ apache2 .*

Adding it to your sudoers(5) will guarantee that you will be able to run any argument to the apache2 init script as root. Whether or not this is safe depends on how the service operates. There is nothing intrinsically dangerous about using an asterisk, but some commands will allow you to execute other commands as arguments. For example, permitting tar(1) with any argument could result in arbitrary command execution in the form of tar --use-compression-program=./evil.sh. I am not aware of any way to execute arbitrary commands, but that does not mean there are not any, or that there will not be any in the future.

It is generally assumed that a person who is able to execute a command that manages services is already in a privileged position, so there will be little attention put into ensuring that the apache2 init service or the service-managing commands cannot be abused when run as root.

If you consider this "exploiting the program with false input" and thus out of scope, it is safe. The sudoers entry will not allow you to, for example, run service apache2; ./evil.sh as root.


As @sonofaaa mentioned, in the book, "The Art of Software Security Assessment", the authors discuss code-auditing strategies in Chapter 4 (end of Part I).

In particular, external flow sensitivity (data flow and control flow) and tracing direction (forward or backwards slicing) are discussed along with many neutral methods of review. Other topics are discussed in great detail. It's the best written material on the subject of secure code review.

I should also mention "Secure Programming with Static Analysis" -- a book by Brian Chess and Jacob West of Fortify Software. They cover the internals and use of security-focused static analysis tools and compare them to other forms/tools in the secure code review world.

If you want to check out modern security-focused static analyzers, I suggest that you first get involved with some open-source or free tools such as CAT.NET for .NET (typically C#, VB.NET, and/or ASP.NET), find-sec-bugs (or the older LAPSE+) for Java Enterprise and JSP, and RIPS Scanner for PHP. You won't commonly find security-focused static analyzers that support dynamic languages, because they don't rely on a type system, but let me know if you are interested in support of Python, Ruby, or another dynamic language (or any other language) and I'll try to point you in the right direction. For starters, try Bandit (OpenStack project for Python code) and Brakeman Pro for Ruby.

Commercial security-focused static analyzers are meant for highly trained and specialized application security oriented developers. The cost of them assumes that someone will be running and analyzing these tools daily, as a full-time job, all year round. If you are interested in seeing quick results -- check out HPFOD -- but if you are interested to integrate these tools into a long-term, at-risk application portfolio for a large-installation -- check out Cigital ESP. There are also many application security boutiques and consulting shops that run and tune these tools for their clients. Depending on your locale and strategic direction, I would choose to partner with one regardless of anything else I mentioned, as they can be invaluable to success of an appsec program. Searching on LinkedIn for "application security consulting" should work if you don't where to go next.


Is it possible to verify identity of site that sent request to you?

As an alternative to having the widget "report back to home," you could write a simple robot that crawls the websites and verifies that the the websites are indeed hosting the widget.

To avoid fraud, you would build the robot with the following considerations:

Hidden identity. Make sure the site isn't only serving widget to robots by disguising your robots identity.
Random crawl sampling. Ensure that your crawling uses a random sampling for when you crawl the sites. This prevents a site from anticipating the crawl and serving it only during that time.
Verify that the widget is visible. Don't only check for the existence of the widget, but that the widget itself is visible and not hidden.
Manual overview. Have your robot generate screen captures so you can review manually whether the widget is appearing.

There are some inherit difficulties that you will be faced based on the "pay-per-view" nature of leasing (to what extent, I do not know because I don't know the specifics of your agreement). The biggest problem is not people placing the widget in non-authorized URLs, but rather abusing the system by automatically (fraudulently) crawling the site to boost view counts. That should be your primary concern, as it is where the majority of the fraud will stem from.

The problem is, it is difficult to verify the legitimacy of a view from an embedded widget. With only access to JavaScript, you have limited capabilities for differentiating between a robot, a user constantly hitting refresh, and a legitimate user. Without access to the server side, your best option to prevent fraud is through browser fingerprinting. This will assist you monitoring abuse of your widget via constant refresh, et al. It is not a catch-all because it is still vulnerable to no-js / torbutton  users which can spoof identities, but it does provide a good first-level of protection to repeat view fraud.


1. How to properly accept and store a new document.

I would recommend to store files in the database, not separately. A) File system is not transactional. That's why it is hard to keep it consistent with database. B) Creating of backups and restoring of particular versions from backups can lead to inconsistencies between file system and database: Database can contain references to files that don't exist, or there can be files that are not references in the database. Database will

2. How to properly link a PDF file for access.

Take your approach A). Use randomly generated unique IDs. They will not disclose your internal structure of the application (and hide the structure of your file system, if you stick to it).

3. How to store potentially malicious PDF files.

A) Check MIME type. There are many libraries that can do that for you. If the file is not PDF (not one of multiple PDF versions), then reject storing such file.

B) Set some size limit.

C) Use virus scanner (if your company or your provider has such option). Send file to virus scanner. Store it afterwards only if no virus was found.


Salted password + hash - is it really useful?

From your initial understandings:

A rainbow table is, for a given hash algorithm, an exhaustive map from hash outputs to inputs. Given that the table must cover the entire output range, and that a good hash algorithm makes it difficult to predict input from desired output, and expensive to compute the output, it should be very expensive to generate.

As to your questions:

Salting your hashes does nothing to prevent brute-force attacks against your login page. It instead protects against your (or someone else's, if they're using the same hash algorithm as you) DB being compromised and the attacker knowing the hashes. Once they have the hash, they look it up in the rainbow table to find the input that will generate that hash, and enter that in your login page. It doesn't even matter if the input is not the same as the user's password, as they will both hash to the same value.
As noted above, rainbow tables are expensive to generate.

If you use no salt and a common hash algorithm, the table already exists and all accounts are compromised. This is cheap to do.
If you use 1 salt for all your users or a unique hash algorithm, the attacker will have to generate 1 rainbow table and all accounts are compromised. This is a expensive, but perhaps the payoff of getting all accounts is worth it.
If you use a unique salt for each user, the attacker will have to generate 1 rainbow table for each user, regardless of what algorithm you use. This is expensive, and the payoff is 1 account. Hopefully this is not worthwhile.

Salting does not protect against dictionary attacks

The aim is to make the attacker do as much work as possible, enough that it'll be easier to just find the user (or if the attacker is a very clear thinker, your sysadmin) and beat them with a rubber hose rather than commit non-trivial resources to computing rainbow tables.

As an aside, MD5 is not a good hash algorithm in this context, it is far to quick to compute.


There isn't anything inherently wrong with using a free antivirus product for PCI, but you really need to consider your centralized logging. You can't keep the logs for your antivirus strictly on the local workstation and meet the retention requirements.


It is not only possible, it has been documented several times in the past.

http://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-960/GNU-GCC.html

For example, http://www.cvedetails.com/cve/CVE-2008-1367/ shows a memory corruption attack that could lead to various types of compromise, if they were sufficiently exploited.

A compiler is just as susceptible as any other program to bugs and malformed input.


If any third party (such as the IT admin) needs to have access to the files in addition to the owner, the standard solution is to have the third party's public key on each user's keychain, and add the third party as a "recipient" of the file when encrypted. For example, user "userguy" might encrypt a file thus: pgp -se -r userguy -r itadmin a_file.example (that's actually GnuPG / gpg syntax but I believe PGP's command line syntax is compatible). The admin could then decrypt the file using their own private key (for which they'd have the passphrase), and - assuming the admin has every user's public key - re-encrypt the file (if needed) using the exact same command (changing the user's identity for each different user's files, of course).

PGP should come with an "agent" program that supports caching the decrypted (post-passphrase) key of the current user - such as the admin - in RAM, so the key only needs to be entered once per bootup. This is of course slightly riskier, since it increases the time the key spends in RAM and thus might be subject to hijacking by a malicious program or hardware attack (physical or via something like SPECTRE) - but it's a lot more convenient for somebody who has to decrypt and then re-sign (as part of re-encrypting) files all the time.


How to detect suspicious activity on a web and mailserver?

There are a number of ways you could approach this, but the most direct would probably be to set up an intrusion detection system, such as Snort.  It monitors all traffic to the server and can warn you of suspicious activity.
https://www.snort.org/


Potential exploitation of gmail account name policies

I suspect that this is a random email address brute forcing. Your mistake is probably in responding to those registration emails, which is quite likely a fake site run by the scammers. By notifying the site that you've received the email, you've set a precedent to the attacker than the mailbox is alive and attended, and is ok for further spams.

You can create a filter so that if the "To" email address is janedoe@gmail.com, then move to Spam directly.


Do the most common ransomware programs delete the original files as they go, or in a big bulk delete at the very end?

In addition to Angel's response, As seen in the popular ransomware variations that you mentioned, the encryption is done on a file by file basis where one file is encrypted and then the plain-text version of the file is removed, then the ransomware moves to the next file. It may start parallel threads to encrypt several files but the outcome is the same for our purpose. Let's see how it's done by eda2, Cryptowall and CTB-Locker.

eda2 (Opensourced ransomware)
Let's start with the opensourced ransomware namely eda2 while the author removed the code from github, what it did was like this:

    //Encrypts a file with AES algorithm
    public void EncryptFile(string file, string password)
    {
        byte[] bytesToBeEncrypted = File.ReadAllBytes(file);
        byte[] passwordBytes = Encoding.UTF8.GetBytes(password);

        // Hash the password with SHA256
        passwordBytes = SHA256.Create().ComputeHash(passwordBytes);

        byte[] bytesEncrypted = AES_Encrypt(bytesToBeEncrypted, passwordBytes);

        File.WriteAllBytes(file, bytesEncrypted);
        System.IO.File.Move(file, file + ".locked"); //new file extension
    }

It starts checking drives and directories recursively passing each file that matches its criteria (file extension is in its predefined list) to the EncryptFile method and the file is overwritten with encrypted version of it.

Cryptowall 4
Cryptowall 4 is analyzed by Cisco Talos and this diagram shows its encryption process:

There are separate threads run by this ransomware, one of them is "DoFilesEncryption" thread which does the encryption part.

After iterating through the folders and finding the files:

  At this point the real file content encryption takes place, the original file is read in blocks that are 512 KByte chunks. Each block is encrypted with the generated key, using an AES-CBC 256 algorithm, and written directly to the new file (together with the block size in the first four bytes).

And the deletion is like this:

// Move the new encrypted file name in the old original position, replacing the old one

bRetVal = MoveFileEx(newEncFileName, lpOrgFileName,
MOVEFILE_WRITE_THROUGH | MOVEFILE_REPLACE_EXISTING);
if (!bRetVal)
// Delete the old file in the standard manner:
    DeleteFile(lpOrgFileName);
else {
    // Rename the original replaced file in the new random file name
    bRetVal = MoveFileEx(lpOrgFileName, newEncFileName, MOVEFILE_REPLACE_EXISTING);
}

CTB-Locker
As analyzed here and kinda same as Cryptowall, there's a thread responsible for encrypting files in which this routine takes place:

The file is moved to a temporary file (%TEMP%\<name>.tmp where <name> is determined by the corehash) using the MoveFileEx API call
The temporary file is read into memory
An asymmetric keypair and symmetric secret key are generated
The file buffer is compressed using the DEFLATE data compression algorithm from the zlib library (which is statically linked against the executable)
After compression the file buffer is encrypted using AES-256-ECB
A header consisting of the public key associated with this file and an encrypted infovector is prepended to the encrypted data
The header-prepended encrypted buffer is written to the temporary file
The temporary file is moved to overwrite the original file using the MoveFileEx API call with the original file getting a new extension (derived from the corehash) appended to it

Further Thoughts & Wrap Up
As discussed above, files are encrypted on the go and usually overwritten by their encrypted version. Now let's analyze this design. In my opinion, one by one encryption and replacement of files is a superior option.

Encrypting files one by one is easy to implement
If the ransomware is stopped midway through operation there's still a chance that some vital files are encrypted and victim is willing to pay
Extra disk space & complex file removal is needed for bulk encryption and then bulk deletion of files

Remaining silent and hidden is one of ransomware's concerns, one other concern is that they have to be fast. They also have to be simple so the executable is as small as possible.
They target unprotected systems, exploit kits used by these malwares target vulnerabilities in applications like Flash, they also make profit from victims that don't have a back up of their data so usually they don't have to deal with hardened and super secured systems. They simply target unprotected not backed up users. They don't have to be bullet proof to be profitable, they just have to be good enough so sometimes they don't have the best implementation possible.

Now in order to deal with performance issues when encrypting large files, one technique I've seen ransomwares using is encrypting only the first n-bytes of the files. This is usually enough to corrupt most of the files and is much faster than encrypting the whole file. Unfortunately I couldn't find the name of the specific ransomware which used this technique at this very moment.

Catching a Ransomware Mid-operation
Refer to What should you do if you catch encryption ransomware mid-operation? for a background, catching a ransomware mid-operation doesn't necessarily allow you to fully stop it or get all your files back.

Ransomwares don't encrypt your whole filesystem, they usually leave executables intact, so the victim has to open up an image, a document or something of that kind to notice there's something wrong.
Even for a computer savvy person who hasn't done some research on ransomwares it may not be clear what's going on, there could be a handful of reasons why a document is corrupted or isn't opening up (Some ransomwares don't change the files' extensions). Adding this to the probability of someone actually noticing that a ransomware is encrypting their files this doesn't seem to be a major concern.

Even if it was a major concern, instead of bulk encryption/deletion, the malware could monitor users activity while staying hidden doing no encryption and once it finds out that the user's inactive/afk it can start the encryption process.


WPA/WPA2 Handshake -- A question on the computation of the MIC

The ANonce that is sent in the first message is indeed not protected. It is randomly chosen by the AP, and is sent in clear-text.

The MIC in the second message only protects the SNonce, and thus cannot be used to verify the ANonce. However, upon receipt of the SNonce, the AP will calculate the PTK, based on:

the ANonce it generated randomly in the first step
the SNonce that it received from the supplicant (which has not been validated yet, as the MIC can only be validated with a valid PTK)

The AP then has calculated the PTK, and can easily verify the MIC, and thus the SNonce. However, if the MIC checks out, it follows that the ANonce probably has not been spoofed, otherwise the PTK calculated by the AP would be different from the PTK calculated by the supplicant (as they used a different ANonce), and the MIC would not check out.

The standard states (of course), that in case the MIC does not check out, the message must be discarded. So, whereas an adversary CAN modify the ANonce, it will lead to a unsuccessful handshake.

Moreover, as an extra defense, the ANonce is again sent in an EAPOL-Keyframe in the 3rd message of the handshake (see image below). The recipient MUST verify that the ANonce in this protected EAPOL-Keyframe is the same as the ANonce that was sent in message 1. Simply said, message 1 is repeated here, but now with a MIC to protect the ANonce, just like you suggested it should be done, however as we did not have enough information to calculate a MIC in step 1, it is done here in step 3. (source: 802.11i standard)

This website has Wireshark screenshots which show you that the ANonce is sent both in message 1 and message 3, and that the 3rd message contains a MIC to protect the ANonce (comparably, message 2 contains the SNonce and the MIC to protect it). I've copied them here for archiving purposes:

Message 1:

Message 2:

Message 3:

Message 4:


The idea with a good single sign on is that there are fewer places for your credentials to be compromised.  There are three reasons to use different passwords, first, because each unique place that stores your password (hopefully hashed) is another place it could get compromised. Second, because if your password is compromised, any other account using it would need to be updated and that is hard to do. Third because if your password is compromised, they could access multiple accounts if they were shared.

SSO is a great advantage for the first two.  A good SSO system should only store your account credentials in one location (which is hopefully far more fortified).  All authentication is done against this one store.  If your account is compromised, rather than having many places to update, only one password has to be changed and one account locked down.

It doesn't particularly address the third concern, but it makes compromise less likely in the first place.  Additionally, depending on the account, different passwords don't necessarily act as much of a barrier.  There are plenty of reported examples of attackers using one compromised account to chain from account to account until they can get to the actual account they want. (For example, if they can access your e-mail account, then they can use password resets.) A good system of reporting compromises and allowing for the account to be locked down can make a decent help towards mitigating the risk though when suspicious activity is detected.

The argument that completely unique credentials may be more secure than a good SSO setup is possibly valid, but in the real world, most people reuse credentials.  SSO mitigates much of the risk of this behavior while still allowing the convenience people want.


Is this system of authentication secure for a mobile app? What can I do to improve it?

Users authenticate with their phone number, get a pin text, and if it is correct, they get an access token.

Phone numbers are PII, so you should be keeping them safe (encrypted?). Text messages are sent in the clear and are readable by smartphone applications, consider that. Also, are the pin numbers random or can they be deducted easily? Are they valid indefinitely?

  The client always sends the access token in an Authorization header.

So if the token is stolen, can the session be spoofed from another phone number?

  Everything is over HTTPS.

Consider testing your TLS settings. Default settings are not secure in most cases. There are online services that help you with this.

  Tokens are just random, long alphanumeric strings

How random, how long? Can the token be brute-forced? Do you hinder login attempts after a few failed ones?

  Is this reasonable? Is it secure?

As a commenter asked, what is your threat model?

  Should I use some preexisting paradigm?

Yes. Don't roll your own.


Full Disk Encryption, Single User System: User/Root Passwords required?

In modern versions of windows and most *nix distributions you typically run with lower level privileges and then elevate your privileges ("run as" / UAC / sudo / etc.) to do more risky tasks. In some cases there is just a prompt, but a more secure configuration would require the password each time you elevate.

If a malicious script or malware runs and want the hire privileges, the password can act as a gate. If you are always running as root or Administrator without a password, malicious software or scripts may just run commands on their own.

Full Disk Encryption only protects the data when the system is off; when the system is live the data is plainly accessible. The password or key you use for FDE serves a different purpose from operating system and user passwords. You can choose not to have a password on user accounts, but the FDE doesn't really protect against the same types of threats.


"Vaultless" or "Reversible" Tokenization - Is it really just encryption with a fancy marketing name?

The line between Encryption and Tokenization is blurry.

The answer to your question is that it depends. There are different ways of accomplishing vaultless tokenization. These different breeds of vaultless can be categorized into two main ideas: lookup table techniques, and format-preserving encryption (FPE).

Using FPE is obviously encryption at the very core, so calling it tokenization is a little bit of a marketing play, however, the justification of calling it a token has to do with what is produces, not how it was created. FPE, although it is encryption, can produce a ciphertext that is the same length and format as what was passed in. In this way, FPE produces "tokens" in the aesthetic sense. However, these tokens were generated using a mode of AES encryption, and so in the eyes of security, these tokens must be treated like encrypted data.

The other breed of Vaultless uses pseudo-random values and maps them to the input (i.e. lookup tables). How is this method considered vault-less? Well in order to eliminate the need for a vault (aka a big database), you must reduce the number of entries in the lookup tables, to reduce its size. If you can come up with a way to keep the size of the table down (!!! while also maintaining the reversibility of the lookup process) then you can justify calling this thing vaultless. Most lookup table varieties of vaultless use tables that are small enough to be stored in cache or something.


How to confirm if a site is using Device Fingerprinting

Unless they are pulling in a known off the shelf fingerprinting script you would have to look at what their client side code is doing.

Probing for available fonts and add-ins isn't necessarily malicious - both can be for improving user experience. Generating a list of all of them a sending it up to a server is more suspicious.

Instead passing the list locally through a hash function and sending the result to a server is almost certainly fingerprinting (I can't think of a single non-fingerprinting use case for this).

If you are asking about detecting fingerprinting automatically I'd suggest the best you could do is looking for segments of known fingerprinting code or communication with known fingerprinting services.


Should we keep logs forever to investigate past data breaches?

There is no "correct" answer to your question, unfortunately. Data retention policies are specific to the needs of an organization, and are often implemented out of necessity to comply with various legal requirements , which vary depending on the nature of the data being stored, as well as the jurisdiction that the data falls under.

Retaining log data can allow for post-mortem analysis if a breach is discovered, as you're alluding to in your question. However, retained data can also be a security risk in its own right if the logs contain sensitive information, so steps must be taken to secure log files if necessary. The other obvious factor in play is the cost of keeping the logs. Depending on availability requirements, different backup solutions may be more cost effective than others, such as keeping old logs  offsite on tape storage rather than using disk redundancy.


InfoSec consultancy - infrastructure vs development

"Secure coding best practices" is not a typical thing to get a consult on and is a little like asking "how not to get sick". It's a pretty broad mandate. It is so context-dependent that I'm not sure how a consultancy could satisfy the mandate as specified.

One typically gets trained in a specific language's secure coding best practices and in a specific use-case (API development). And once you niche down the problem-space, the answers tend to reveal themselves.


Why is the same origin policy so important?

Why is the same origin policy important?

Assume you are logged into Facebook and visit a malicious website in another browser tab. Without the same origin policy JavaScript on that website could do anything to your Facebook account that you are allowed to do. For example read private messages, post status updates, analyse the HTML DOM-tree after you entered your password before submitting the form.

But of course Facebook wants to use JavaScript to enhance the user experience. So it is important that the browser can detect that this JavaScript is trusted to access Facebook resources. That's where the same origin policy comes into play: If the JavaScript is included from a HTML page on facebook.com, it may access facebook.com resources.

Now replace Facebook with your online banking website, and it will be obvious that this is an issue.

What is the origin?

  I can't really fully understand what same origin domain means. I know it means that when getting a resource from another domain (say a JS file) it will run from the context of the domain that serves it (like google analytics code), which means it can't modify the data or read the data on the domain that "includes the resource".

This is not correct: The origin of a JavaScript file is defined by the domain of the HTML page which includes it. So if you include the Google Analytics code with a <script>-tag, it can do anything to your website but does not have same origin permissions on the Google website.

How does cross domain communication work?

The same origin policy is not enforced for all requests. Among others the <script>- and <img>-tags may fetch resources from any domain. Posting forms and linking to other domains is possible, too. Frames and iframes way display information from other domains but interaction with that content is limited.

There are some approaches to allow XMLHttpRequest (ajax) calls to other domains in a secure way, but they are not well supported by common browsers. The common way to enable communication with another domain is JSONP:

It is based on a <script>-tag. The information, which shall be sent to another domain, is encoded in the URL as parameters. The returned JavaScript consists of a function call with the requested information as parameter:

<script type="text/javascript" src="http://example.com/
     ?some-variable=some-data&jsonp=parseResponse">
</script>

The dynamically generated JavaScript from example.com may look like:

parseResponse({"variable": "value", "variable2": "value2"})

What is Cross Site Scripting?

Cross Site Scripting is a vulnerability that allows an attacker to inject JavaScript code into a website, so that it originates from the attacked website from the browser point of view.

This can happen if user input is not sufficiently sanitised. For example a search function may display the string "Your search results for [userinput]". If [userinput] is not escaped an attacker may search for:

<script>alert(document.cookie)</script>

The browser has no way to detect that this code was not provided by the website owner, so it will execute it. Nowadays cross site scripting is a major issue, so there is work done to prevent this vulnerability. Most notable is the Content Security Policy approach.


Buffer Overflow doesn't have enough space for exploit after being crashed

Assuming that you're talking about a vanilla EIP overwrite and not something like SEH, you have two options available to you. Neither of these are what I would consider to be "beginner" techniques as they require a bit of Assembly knowledge though there are some great websites that can help you out.

1. Employ an Egg Hunter. An egg hunter involves sticking a small bit of a shell code in a limited buffer space and then prepending a 8 byte egg (ie n00bn00b) before your shell code. The egg hunter will search through memory for your unique egg and then jump to the shell code that follows it.
Example buffer Variable

buffer = "\x41" *100 + "n00bn00b" + shellcode + "\x90" * 50 + egghunter + offset + jmpback

Where above "offset" could be a simple JMP ESP in a DLL and "jmpback" would be an assembly instruction to jump back into the buffer to somewhere in the nopslide.

While it looks a bit confusing the execution flow is as follows

The offset variable is placed where your EIP overwrite is. This variable simply holds the address to a JMP ESP instruction which then points to the jmpback variable
The jmpback variable holds an assembly instruction (ie \xeb\xc4) which jumps back into the nopsled.
The egghunter shellcode runs and begins searching for the n00bn00b string.
When the n00bn00b string is found it jumps to the shellcode which executes.

The Egghunter is a great way to give yourself some more buffer space.

2. Jumping backwards into the buffer : The second option, if the buffer space is available to you, is to issue some assembly instructions to jump further back into the buffer to execute your shell code. This sounds like the easier of the two options, however it's possible to trash the stack if you're not careful to re-align the stack after shell code execution.

If you have a clean overwrite of another register, such as ECX, it might even be possible to just JMP ECX to fire your shell code.

Note that this answer assumes that things like DEP and ASLR are not enabled on the machine you're attempting to exploit.


What does the HTTPS server verify when it asks for a client certificate?

I assume that the only thing the server checks, is that wether the IP on the certificate matches the one for the current TCP/IP connection, ...

That is very likely a thing the server does not check. Client certificates at least for HTTPS are usually not issued for a domain or IP, but for a user - because they are used to authenticate a user and not a system.

... that the certificate is signed by an authority the server trusts

This should be checked.
Additionally one might check for a specific subject of the certificate or the web application might decide based on the subject which user this is.


When signing email with GPG, how does verification by the receiver work?

There is a unique association between public and private key. That is, if the sender uses a certain private key to sign a message and you verify the signature using the corresponding public, then the signature verification will succeed only if the message has not been altered.¹

The verification procedure and nature of the association between public and private varies with the cryptosystem you are considering (RSA, DSA, etc.), but the statement above holds true for any asymmetric scheme.

What really matters is that the sender is the only one that can produce a valid signature because he/she is the only one who knows the private, but anyone knows the public, so anyone can verify the signature.

Upon signing, GPG adds a token to the text message which can be used to verify that the message has not been altered in transit: that's the signature. You don't need GPG to read the message because the text itself is not encrypted, there is only an extra token, which could be either a radix64-encoded blob at the end of the message or a text attachment with a similar structure.

GPG does not directly sign the message², it signs a cryptographic hash (SHA-1 or SHA-2 usually) of it. What happens upon verification is that the signature is verified using the public key of the sender to make sure the received hash was actually originated by the sender. If the hash calculated by the sender is considered authentic, it is compared with the hash calculated by the recipient. If both phases succeed, then the message is correctly signed.

[¹] actually, there is a theoretical possibility to break this rule by generating a so-called hash collision. That is to say, a different message with the same hash (see the last paragraph). Collisions have been generated for MD5, while finding one for SHA-3, SHA-2 and SHA-1 is considered unfeasible, although the security margin over the last one is becoming so thin it's advisable to stop using it now.

[²] for some cryptosystems, like DSA, signing a hash is the only possibility.


Does this official "Enforce MFA" AWS policy make any sense?

To delete an MFA device, you should first deactivate it. If it is deactivated, you cannot use it for MFA any more. Thus, it makes sense.


What provides better safeguards against decryption/hacking: HTTPS or a well-made mobile app?

I think what you're asking for is whether Browser or Mobile App is more secure because HTTPS is used in both. Most mobile apps are similar to webpages and use JSON and Restful APIs. In that case, App is potentially more secure because you have more control on the client side, and you can use SSL Pining and the users can't be tricked with typosquating or something.


Is Schneier's "Applied Cryptography" current?

It's still pretty good as long as you are aware of what it's missing. My short list, keeping in mind my interests are only for a small subset of cryptography. Also keep in mind I don't know the book by heart and went by the index to confirm my memory, stuff may still be there but under another entry

Regarding algorithms, their mode of operations and protocols using them:

No AES, AES came a few years after the book
No SHA-2, came even later than AES
MD5 still represented as viable, as it was at the time
ditto for SHA-1, which is still true but not best practice anymore
no GCM chaining mode, that is now decently popular
no specific SSL/TLS, x509, ssh or OpenPGP discussion whatsoever, that would cover a good 90% of the practical cryptography usage we see today

Regarding attacks, missing a whole lot of attacks that were discovered/popularized later

differential power cryptanalysis
differential timing cryptanalysis
fault inducing cryptanalysis (I'm likely not using the right term here)
attacks on protocols using their error reporting, e.g. padding oracles

Those missing attacks are pretty important as e.g. most naive implementations are very vulnerable to them and it's very hard to harden aware implementations against those.

The consequence is that the book cannot be relied on at all for current best practices for the implementor, but is still very educational on the subject. But unsurprisingly, the field changed a lot in 15 years.

Also the book is very light on still used protocols, very heavy on exotic primitives, so of little practical value for people using crypto primitives as tools packaged in a library to implement practical solutions.

I would not buy one new today.