How to obscure client keys from network interception or MITM To use our platform and APIs, a client requires integration of iOS and Android SDK on their mobile apps. Each of the clients is issued one API key, like any other platforms such as Crashlytics, MixPanel, etc., to communicate with the server.

We are trying to obscure the keys during any kind network interception or MITM. However, this seems to be a tough job.

So far we have tried following:
1. Storing the client keys in the key store, keychain.
2. Change the header, JSON parameter names to confuse the attacker.
3. Putting the keys in a file and then transmit it over the network.
4. The first and last call method. We are hashing the first request timestamp and then comparing it with the next consecutive calls. If the timestamp is greater than the first timestamp, then we can assume that an attacker isn't trying to replay the calls for abusing the platform.

We cannot allow keys to be seen by the attacker for a reason, each and every call is being billed to the client, and anyone aware of our platform can cause tremendous damage to our customers just by replaying the requests to our server.

How do we ensure that keys are securely transmitted and are not visible to the attacker?

Note: Once the SDK on a mobile app goes live, for a client, we are updating the keys at different hours of the day and storing in the keychain, keystore.

Thank You
Fennec

This depends on the kind of attack you expect:

If the attacker is purely on the network trying to do a man in the middle attack then protecting the connection with TLS (i.e. HTTPS) should be sufficient. Additional protection can be added by using certificate or public key pinning.
If TLS/HTTPS is not an option you can used digest based authentication for a proof that the client owns the token. You could of course also combine it with TLS.
If you fear that the attacker can get access to the app and extract the key you've lost anyway. In this case you can only try to limit the impact, i.e. use code obfuscation to make reverse engineering and extracting the key harder, employ rate limiting to limit abuse and change the access key and obfuscation strategy often enough, i.e. ideally before the key gets exposed.


How to convert risk scores (CVSSv1, CVSSv2, CVSSv3, OWASP Risk Severity)? Is there an accurate method or formula to convert risk scores between the OWASP Risk Rating Methodology (Overall Risk Severity) and the CVSS v1, v2 and v3 models) base score)?

As well as converting scores between the different CVSS versions? For example convert a CVSSv1 score to a CVSSv3 score or visa versa.

I am the lead architect of a very popular vulnerability database and we face similar problems. At the moment we have nearly 90'000 vulnerability entries with a CVSSv2 base and temp score. We are adding CVSSv3 scores and trying to convert most of the old data. I am going to discuss this transformation only to illustrate the basic principle of such.

The most important aspect is: Do not try to convert the scores themselves - Transform the vector into the new format and re-calculate their new scores instead.

If you take a look at the user guide of CVSSv2 and the specification of CVSSv3 (generic link might change in the future) you can see that some of the base vectors might be transformable:

AV (P is new)

N => N
A => A
L => (L|P) (usually L)

Au => PR (needs manual optimization)

N => N
S => (L|H) (usually L)
M => (H|L) (sometimes H)

CI / II / AI (see comments below)

C => H
P => L
N => N

E

H => H
F => F
POC => POC
U => U
ND => X

RL

OF => O
TF => T
W => W
U => U
ND => X

RC (some deviation)

C => C
UR => R
UC => U
ND => X

But there is some additional complexity regarding other vectors:

AC in v2 is now somehow split into AC and UI
Even though CI, II and AI stay the same, v3 has added S. In most cases a CI:C/II:C/AI:C might promise a S:C sooner or later which might be derived by default.

If you follow this definition you might be able to convert approx. 97% of all issues without touching them manually. The deviation in accuracy during such a transformation is usually very small.


SSL Handshake problems I captured my network traffic to a web server and the SSL Handshake consists only of two packets.
Why does that happen and why aren't there all the other packets?

You're probably seeing session resumption.  If the Client Hello and Server Hello packets both have the same Session ID value, then the handshake is shortened as the Client and Server 'recognize' each other.

To quote RFC 5246:

  The client sends a ClientHello using the Session ID of the session to
  be resumed.  The server then checks its session cache for a match. If
  a match is found, and the server is willing to re-establish the
  connection under the specified session state, it will send a
  ServerHello with the same Session ID value.  At this point, both
  client and server MUST send ChangeCipherSpec messages and proceed
  directly to Finished messages.


How do these attackers find my IP? Recently, I have been reading a lot of my ubuntu log files (in /var/log/auth.log), and I can see that some IP addresses are actually trying to 'brute-force' their ways into my VM using SSH by testing a lot of very simple combinations (like root usernames, or very common apps usernames such as php or mysql).

Just curious, how do these attackers find about my particular IP? Are they performing this attack on a lot of different machines at the same time or is it just me?

There are just about 4,294,967,296 available IPv4 addresses on the Internet. That's not that much and with some Bots they attack the whole IPv4 address space randomly (Incrementing the IP or just try and error). In some cases they find a machine which is bad configured or outdated which makes them attackable with well known exploits also known as CVE's. If an attack is successful they can do whatever they want with the machine like integrating them into a botnet or other bad things and move on to the next address. With IPv4 that's easy but not with IPv6. If you want to minimize your attacking surface try to switch to version 6. It's harder to find some machines with so much more addresses available. I got also much attacks every day on my router. That's why it's so important to update your network gateway or other machines.


Somebody bumped into me, next day my storage unit was burglarized While I was walking in the street, somebody carrying a laptop bag bumped into me, and the next day I found out that my storage unit was burglarized and some important items were stolen.

My storage unit door uses a magnetic-stripe card without a PIN, and I have several important items there. The items don't include money or anything that has intrinsic value itself, but they could be important to some parties.

I do realize my mistake, I shouldn't have trusted a storage unit with important items. I should have stored them in a deposit box in a bank.

To help you guys help me, I'll try to give as much information about the situation as possible:

I vividly remember his bag hitting my back pocket in an unnatural way.
I immediately checked my wallet after the bump, I made sure my ID, money, and the card were there.
The stolen items are of some importance to some people and they would hire PI.
I've already informed the police and filed a report.
The security cameras in the storage area hallway show a masked person opening the door normally, and there are no signs of forced entry.

My question is: Could that person have cloned my card when he bumped into me? Is it really as easy as touching the person's pocket? Does the process really take that small amount of time (1-2 seconds)?

Update: After investigation it turned out that the card has an RFID tag inside it, but the storage space operators didn't know about it. It was there just in case they wanted to change the locks to support RFID. The magnetic stripe and the RFID tag both contained the same data, so the thief copied the RFID tag and made a new magnetic card with the information.

Yesterday the police caught the thief after catching the person who hired him trying to sell the items to a blackmarket honeypot operated by the police. I identified the thief as the person who bumped into me and he later admitted.

It sounds unlikely.  As @schroeder says - a mag stripe must be physically run through a reader.  So if you must "swipe" the card to get access, you must swipe the card to copy it.  While a pickpocket can take a card out of your pocket, if the card is still in your possession, it's unlikely that this interaction was part of the theft.

Keep in mind, however, that a single instant in time is not the only case of potential intrusion:

any time the card was left unattended for any time is an opportunity
any access to a master card is an opportunity - generally a storage unit will have a master key card - they are loaning you this space, if you default on your rent, or the police have a warrant, they will need to access your space.

Whichever card is used as a source, making a copy should leave no evidence on the card.

It maybe possible, from digital logs, to see what card was used for access at the time of the break-in.  Was it your card?

Chances are, you and the storage space management need to think through who had access to the cards that control your space.

Addition:

Backing up a step to a bigger picture.  In any theft, there's a question of due diligence.  Any type of security is tricky, and needs a diligent design and careful implementation.  This particular issue involves:

electronics - the mag strip key card
physical - the access to your door, and the facility at large, as well as video survellience,
personnel - anyone who was supposed to be watching the video, the people with access to the master card, and overall personnel management

The easiest hack is generally social engineering and working in the nexus of areas of security, where there are often human communication gaps.

The general solution is to work with the site as best you can to determine who might have had access.  Accusing them of a lack of due diligence probably isn't going to get the job of finding your stuff done... but sooner or later, you or the PI may need to go there to figure out if you have a insider threat or a fairly clever outside attacker.

As the comment thread shows, there's numerous options out there that are bigger than the incident you mention that are just as (if not more) likely as someone managing to pick your pocket.


Keeping Whois domain registration details private Most domain registers offer a service to keep your details private in the Whois database. Usually this works by replacing your email, telephone and snailmail addresses with proxies or P.O. Box numbers. E.g. http://www.domainmonster.com/domain-name-privacy/whois/

Does this system effectively preserve your privacy and under what circumstances could the register be forced or tricked into revealing your details?

Similar to Ramhound, I also have two domains hosted through GoDaddy. I'm currently working to transfer them over to a better registrar, for privacy reasons. I use their private whois registration (Domains By Proxy). First and foremost, 'our' data is stored on their servers, so if their servers were compromised I suppose an attacker could extract private registrations.

More likely, if a registrar receives complaints or is contacted by authorities, you risk having your information handed over. For example, on DBP's website, at the bottom left-hand corner in the footer there is an area for authorities to request information about a domain and a 'file a claim' section for everyone else (copyright abuse, spam, defamation, etc.). A registrar would be legally obligated to comply with the police, granted they have a subpoena (welcome to America!). Though, there is a trend for companies to cooperate with the police without one, let alone evidence of wrong doing. I can only assume they would also work with attorneys, intellectual property owners, etc.

Although I wouldn't recommend it on a public forum (seeing as it's illegal), various users decide to provide false information during domain registration, that way the whois contains inaccurate information about the domain holder.

You may be interested in an article, "Private Domains Not So Private?" by CNET. TL;DR: DBP decided to drop a private registrar's account (without notice), therefore exposing his credentials simply to avoid the heat of hosting a controversial domain's registration.


If two endpoints establish a mutual authenticated connection (TLSv1.0) is the medium between the endpoints a concern? What are the vulnerable areas when two endpoint connect via TLS? Does the physical layer or data link layer a factor of security concern between the two endpoints? Does it matter in terms of security, that some portion of the link between the two is wireless?

The actual physical layer or data link layer do not present a security concern as long as you force mutual authentication and use a properly secure ciphersuite.

There is no direct risk with physical layer access. There is a future risk with it.

As somebody with access to the physical layer or data link layer has the possibility to store all traffic indefinitely, they can use future techniques and processing power to crack the current connection. If the data you transferred is only relevant in the now, no issue there. But keep that in mind when selecting a proper ciphersuite to use and determining the size of your certificate keys.

The security in your connection also relies on the certificates used and their trust-root. So the CA that is used for authenticating both sides is a security issue, as somebody able to compromise the CA can possibly also listen in on or manipulate future connection and/or spoof endpoints.


Difference between an "Information Security Policy" and a "Cybersecurity Strategy"? What is the difference between an "Information Security Policy" and a "Cybersecurity Strategy"?

I had an argument about this with my management and whilst some think that its basically the same thing, others were adamant that the policy is different to the strategy.

There is a massive difference between "Information Security Policy" and a "Cybersecurity Strategy". As the name suggests they are policies and strategies respectively and the management often gets confused between the both. However I believe following points will help explaining the difference.

An information Security policy is an individual document which will:

Enumerate the elements that constitute IT security or information security.
Explain the need of IT security.
Categorize the various types of IT data, i.e. equipment, and processes subject to this policy.
Indicate, in broad terms, the information security responsibilities of the various roles in which each member of the organization may function.
Indicate appropriate levels of security through standards and guidelines.

Where as a Cybersecurity Strategy will comprise of But not limited to

Information Security Policy
Information Sensitivity Policy
Incident Response and Disaster Recovery Plans
Change control procedure
Configuration Standards
Many more policies, guidelines, standards etc which will collectively contribute in how the organization will anticipate/respond to a Cybersecurity threat/incident.

I do understand that some of the elements will be highlighted in Information Security Policy but looking at the bigger picture not everything will be covered. Hope this helps in anyway.


Can I use the same password both for SRP and for client-side encryption? Suppose a less-than-trusted server is used to store users' confidential data (encrypted at the client side), and both tasks - authentication and encryption/decryption - should be doable with a single password. Would it be enough to:

Strenghten the password with a slow key derivation function and a trivial salt [1], yielding k;
Use k as the SRP "password", authenticating with the server and receiving the ciphertext;
Decrypt the ciphertext to get the actual key(s) to be used for signing, encryption, etc.

A malicious server (low risk) would have to perform an offline dictionary attack - on the verifier or on the ciphertext - to retrieve k, while an external attacker (higher risk) would only be able to do online attacks (since he has access neither to the verifier nor the ciphertext), unless he gets a copy of the database - which would just put him in a similar situation of the server [2].

Is this reasoning correct? Any flaws I didn't anticipate? Some notes:

I say the salt is "trivial" because it's either: a) empty; b) derived from the username; c) random, but the server will give it to anyone who requests it. Normally that would be a concern, but here the key never leaves the client machine, so it doesn't matter if two users have the same key.
One of my concerns is that an attacker could create a rainbow table targeted at a particular user, then get the database and almost immediatly log in as that user, since brute-forcing the verifier or the ciphertext is quicker if you have a list of candidate keys rather than a list of candidate passwords (which still need to be stretched before becoming keys).

Of course, if an attacker has that computing power (of if the password was weak) any leaked ciphertext will eventually be cracked, but future harm could be avoided if the server were stronger against this scenario (before learning about SRP I designed a more convoluted protocol that took this into account, but was more wasteful and had open questions).
[For my particular case] All these are out of scope of the question (assume already figured out): all communication will be over TLS, option to use proper keys and 2-factor auth will be given (but not mandated), the client code will not come from the less-than-trusted server, MACs will be used, etc.

As an exercise in healthy cautiousness, I would advise the following:

When you derive your key k from the user password, make it longer, and split it in two. Use the first half for SRP, the second half for encryption. A simple way to achieve that is to hash k with SHA-256, yielding 256 bits which can then be split into two fine 128-bit keys. Alternatively, use a key derivation function with tuneable output size, like PBKDF2.

The point here is that we want to avoid any unwanted "interaction", however implausible, between the symmetric encryption and the computations performed in SRP. Intercalating a layer of one-wayness between the two subkeys ought to prevent such issues (assuming SHA-256 to more or less behave like a random oracle).
You encrypt for a reason: you then must assume that an attacker may observe, at some point, the symmetrically encrypted data blob. Otherwise, what would be the point of encryption ? But if such an eavesdropping is possible, then the salt must be proper. An empty salt would not cut it, because all users would use the same salt, allowing for attack optimisations (namely, rainbow tables).

Now there is an interesting point, which is that SRP itself includes some salt processing. Take a close look at RFC 5054, which describes how SRP is to be integrated in a TLS handshake. In the initial step, the client (in its ClientHello) sends the user's identity (I). The server responds with some messages, including the ServerKeyExchange which contains (among other values) the salt s. So you have, right here, your "server which sends the salt to everybody who asks for it".

The actual password processing, in SRP, is the computation of x = SHA1(s | SHA1(I | ":" | P)). This is a salted, but insufficiently iterated password hashing function. This is a known flaw in SRP as it is currently defined. However, it would be trivial to replace this operation with a strong password hashing function, as long as client and server agree.

This then yields the following scheme:

At registration time, the user chooses his password P, and a random salt s is generated (say, 128 bits from a cryptographically strong PRNG).
From P and s, a strong password hashing function (such as bcrypt) is applied, yielding some intermediate value z, which we then hash with SHA-512, yielding 512 bits. These 512 bits are split into two 256-bit halves; the first half will be the x value for SRP, while the second half (let's call it y) will be used for symmetric encryption.
When logging in, the client first send the user name (I) to the server, and gets the salt s. The same computation of x and y is done again. The x part is used for SRP, the y part to decrypt the blob stored on the server.

This scheme combines all the points discussed above. Password-to-key derivation uses a proper function with a good, random salt; there is an isolation layer of SHA-512 between the two usages of the password; no extra message exchange is needed compared to basic SRP. In effect, what I suggest here is a strengthening of the password hashing done in SRP, with an extra leeching of a password-derived key for your symmetric encryption need.

Note that while you can first establish a SSL/TLS tunnel and then perform SRP in it, you can also follow the RFC 5054 road and use SRP for the TLS handshake. This would require control of both client and server code, including the SRP implementation, since I am suggesting here modifying the password-to-key derivation process (namely, to strengthen it). Correspondingly, the client must already have the needed code. In a Web-Javascript context, you would need first a "normal" SSL/TLS, although at that point the benefits of SRP become quite small.

Letting the server send the salt value to whoever asks, as is inherent in SRP, is not a serious issue. Salts don't need secrecy. Keeping salt values secret does not harm, but this is only a secondary goal. The main point of salts is uniqueness. Don't let an unwarranted itch for secrecy get in the path of uniqueness.


For CA-signed ssh keys, how to see various attributes: principals, identity, serial number, options, validity time, etc I am looking to implement access controls through CA-signed public ssh keys, as described in the article Scalable and secure access with SSH.

I am trying to conceive how our security team will manage this on the CA side.  One thing I would like to be able to do is, after signing a key, I would like to "query" that key to get information about it.  In particular, for a given key, I'd like to know:

With what CA was it signed (i.e. can I extract some information about the certificate used to sign this key)?
What identity has been assigned to this key (-I flag to ssh-keygen)
What principal(s) are allowed by this key (-n ssh-keygen flag)
What is the validity time for the signature (-V)
What is the serial number of this signature (-z)
What options have been assigned to this signed key (-O)

Clearly, sshd necessarily needs to decode all those attributes when the key is presented.  Is there a programmatic way to extract that info?  I am thinking in terms of sanity checks, auditing and reporting on the security team management side.

Edit: I realized I was using incorrect terminology in this post.  From the ssh-keygen manpage (emphasis mine):

  ssh-keygen supports signing of keys to produce certificates that may be
  used for user or host authentication.  Certificates consist of a public
  key, some identity information, zero or more principal (user or host)
  names and a set of options...

As Abraham mentioned below, keys are indeed just keys.  Once a key has been signed by a CA, it is no longer just a key, but a certificate.

Lastly, in a stunning display of RTFM Fail, ssh-keygen -L -f certificate does exactly what I need.

My cohorts at Gravitational wrote a pure golang tool that parses SSH certificates and run it online here: https://ssh-certificate-parser.gravitational.com/ If you are asking about parsing signed SSH certificates I believe that tool will output all data that's available within the certificate.


Is sending "Access-Control-Allow-Origin: http://localhost:8888" dangerous? I recently found the following HTTP headers on a site that could at the very least be described as a high value target:

Access-Control-Allow-Origin: http://localhost:8888
Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: [some custom non-standard headers]

This looks weird to me, or at least not compliant with the CORS RFC:

  The Access-Control-Allow-Origin header indicates whether a resource can be shared based by returning the value of the Origin request header, "*", or "null" in the response.

The returned value is obviously not my Origin request header (or * or null). So, my questions are:

Is there any good reason for sending these headers? To me it seems like something used in testing that have accidentally leaked into production.
Is it possible to exploit this in any way? Seems unlikely to me, since only a tiny minority of users will have anything running on that port, plus an attacker would not be able to control it anyway. But maybe I am overlooking something.
Is this something that warrants contacting the site in question to inform them about the issue?

For an attacker to make use of this CORS header, he must run Javascript on localhost:8888. Inspired by your question, I looked for a service that runs on localhost:8888 and allows an attacker to run Javascript. I found one:

MAMP is a webstack that runs on port 8888 by default, and comes with the vulnerable SQLiteManager. SQLiteManager has several vulnerabilities, one of which is XSS using CSRF, so an attacker could trigger Javascript remotely to run in the context of localhost:8888. It would then be able to read data from your high value target.

This attack is not really probable, since it would only work for users that are both visitors of your site and users of MAMP. Furthermore, MAMP also has a remote code execution vulnerability, so the attacker does not need the CORS header to read HTTP responses.


SSL Auth to proxy using Certificate on Client-side The question may need to be reworded.

The server-side is set up with Squid3 acting as an Authenticating proxy by way of LDAP. I did this for testing purposes to make sure everything was working.

I would like to have the client-side authenticate using something like a certificate or the like so that the need to physically put in cred isn't needed.

Is this a possibility? This is my first real jump into this sort of thing, so by all means ask for more clarification and I will do my best to be more specific (if possible, haha)

Are you asking if it is possible to negate the need for "login" authentication by using certificate based authentication?

If so, then yes you certainly can provided that your users don't have roles which determine their access levels to the service (authorisation). Furthermore, you could also achieve mutual authentication so that both the server and client identify themselves as authentic (prevent man-in-the-middle attacks). I recommend that you research SSL and see what it can do for you!

I hope this is useful to you :)


Using Nmap kicks me out my own network I am working on a school task, where I have to use Nmap in order to scan for open port on another device on the same network. However, when I use Nmap my network suddenly gets limited. I have tried Nmap GUI on Windows where I write the target IP-address. I am doing this at home with my own laptop.

I'm not sure how stable your network is, but maybe you are creating too much traffic for it to handle. I would start by doing a simple scan on the one up address with a slower speed to verify. Example:

nmap -sS -T2 -p 0-1000 192.168.1.25

Please note to change the IP address to the one you know is alive.


What security purpose do hashes of files serve? Many websites offering downloads also provide the MD5 or SHA1 hashes of the files which are available for download.

An example-

What is the security purpose behind providing such a facility to the end-user?

A cryptographic hash function is a function which everybody can compute efficiently (there is nothing secret about it), and which offers some interesting characteristics:

It accepts as input a sequences of its (or bytes) of arbitrary length (in practice without any upper bound).
Its output has a fixed, small size (128 bits for MD5, 160 bits for SHA-1).
It is deterministic (hash the same input twice, possibly with different machines or implementations, and you will still get the same output twice).
It is so much entangled that it resists collisions, preimages and second preimages.

For the scenario at hand, collisions are not an issue. Preimage resistance is about the impossibility of finding a message m which, when hashed, yields a given output. Second preimage resistance is similar: you know a message m, which, when hashed, yields some output x, and you cannot find another message m' (distinct from m) which yields the same output. How this impossibility is achieved is a rather complex subject (see this).

The small output size is the reason we use them for downloads. If you obtain the MD5 hash from a reputable source (the SSL-enabled Web site of the publisher), then you can download the actual data from anywhere, e.g. a P2P network like BitTorrent. Once you have the data, you hash it (on your machine) and then check that the MD5 or SHA-1 hash value matches the one you got from the reputable source. On match, you know that you have the right file, down to the last bit, because, in order to feed you an altered file while keeping the correct hash value, an ill-intentioned attacker would have to break second preimage resistance of the hash function -- and, right now, nobody knows how to do that.

If you download the file from the same source as the hash value, then the hash value is kind of useless. The added value for security of the published MD5 or SHA-1 is in the situation where the bulk data is obtained through a "weak" medium, while the hash value is transferred securely.

Hash values are also great for detecting errors. They are meant to resist modifications of the data by intelligent attackers who know what they are doing; this also makes them robust against random alteration from a mindless universe. Hash functions are very good checksums. If you download a big file, say an ISO image, burn it on a DVD, then read back the DVD on some other machine, then there is ample room for non-malicious alterations, in particular bad RAM on either machine (flipped bits occur more often than usually assumed). At any time, you can recompute the hash on the data, and see if it matches the expected value.


Using TPM for full disc encryption? E.g.: Can I make a better full disc encryption with e.g.: LUKS using the TPM? How?


What's the difference between the same model with and without FIPS 140 certification? We all know that there is a lot of FIPS 140-2 certified hardware available. However many hardware platforms come with either different grades of certification (e.g. level 2 vs level 3) or are branded very similarly but have no certification at all.

What is the actual or usual difference between HSMs and similar devices which have FIPS / CC certification in one model and no or less certification for another model?

As an example I'd like to name the Thales nShield HSMs which are available with level 2 and level 3 certification, the Gemalto ID Prime MD smartcards which have FIPS and Common Criteria certification for one model (830), only CC for another (840) and nothing for a third (3810) and the last but not least the considerations of Yubico to launch a FIPS certified YubiHSM for a much higher price-tag.

[Disclaimer: I'm a developer on a FIPS 140-2 Level 2 software module, and I'm a little disgruntled about the whole process]

The main difference I've seen is that things that are FIPS 140-2 certified are at least 6 months out of date when you get them, and cannot be patched in the case of a vulnerability.

Getting something FIPS / CC certified costs $$$, developer effort, and about 6 months of waiting. It's completely infeasible to certify patches, especially emergency security patches. Once we have a commercial FIPS-certified build, that build gets code-frozen for X years until we do another FIPS validation, so customers requiring FIPS 140-2 certified software are forced to use an older, unpatched product.

(Of course we try to work around this as best we can by providing our FIPS customers with external scripts / tools, or hacks to code outside the FIPS boundary, but sometimes the fix just has to wait for our next re-validation. The phrase "How do we solve this without breaking FIPS?" comes up more often than you would expect. So our non-FIPS customers actually have a cleaner (and sometimes more secure) product with a faster patch cycle.)

Less snarky:

The advantages of a FIPS 140-2 / CC certified product is that you know it's built on top of other FIPS 140-2 certified libraries (ex. Linux's RNG /dev/random) and that the out-of-the-box configurations will meet a minimum standard for entropy collection, ramdomization, private key protection, etc.

Final note: I'm speaking to FIPS certified software because that's what I know. As @Polynomial points out in his comment, it's possible that hardware manufacturers may omit the intrusion-detection sensors on their non-FIPS models, or may pre-load it with configurations that improve performance at the expense of security (for example, using /dev/urandom rather than /dev/random). I imagine an HSM sales person would be pretty open about this sort of thing (if you manage to get a sales person who's technical enough).


How can pentest reports contribute to structural solutions for vulnerabilities? When you do a pentest what is your recommendation to the client on how to handle/interpret the report?

What I frequently see is that identified issues - especially issues related to self developed software - are not fixed properly. The easiest example is the XSS, which is "remediated" by s/// (replace exactly the XSS String from the report with nothing).

This fix is obviously not a good one - on the one hand because the XSS still exists and on the other hand because this bug is a clear indication that the concept of handling user input is not secure in any way. From my point of view this means that other XSS vulnerabilities are present even though I did not find them. Assuming that a tester finds all vulnerabilities is, in my opinion, unrealistic.

How do I get the client to think like this? E.g., I want the client to say "Oh, you found an XSS! We probably need some technology/process/architecture adaption... to get rid of this stuff as much as possible. Maybe let's use some web-framework and introduce a SAST solution."

I learned that the generic remediation text-blocks at the end of every report are not sufficient at all. What has proven quite effective are remediation workshops - basically discussing the results in a 2-3 day workshop and then supporting devs during implementation. Of course, only a small amount of customers are willing to pay for this (and I don't really have the resources).

Ultimately the responsibility for implementing the recommendations from a penetration test/security review, lie with the owners of the system.

As a consultant, you can make recommendations, so as with XSS you can recommend that the customer ensure they use a robust combination of input validation and output encoding to properly mitigate the risk and you can point out the weaknesses of blacklist filtering or other naive fixes like getting rid of specific characters.

However at the end of the day, you can't stop customers from taking this approach against your recommendations.

Of course, if you're internal to the organization you have more options in that you can try and get security standards for your development teams that lay out the correct way to avoid/reduce the incidence of security issues.


Encrypting/decrypting information in database So, let's say I have a secret message I want to encrypt and store in my database, from where an authenticated user can retrieve, decrypt, read, update the message.

EDIT: the issue I'm encountering is this: It doesn't make sense to use the same password for authorization and decryption. Usually, a hashed password is stored in the database in order to verify the user. But if I use the hash password for encrypting the message too, then all a hacker needs to do once he sees the database is decrypt the message with the hashed password

From doing some stackoverflow searches (http://stackoverflow.com/questions/2388256/secure-encrypted-database-design?rq=1), now correct me if I understood it incorrectly, it seems as if the solution is to encrypt the secret message with public keys, decrypt the message with private keys, and then symmetrically encrypt these private keys with user passphrases. The encrypted private keys can then be stored in the database. So in sum, this is how it works: the user provides a passphrase, which decrypts the private key as stored in the database, which is then used to decrypt the secret message as stored in the database.

Now, my question is this: can you use the passphrase for both authentication and decrypting the message? I don't want hackers to be able to guess passphrases until the private key is successfully decrypted, so some user authentication (i.e. username, password, store hashed password in database) would be good. However, the idea of having to enter both a password for authentication and a passphrase to decrypt the message seems excessive.

I believe I may be misunderstanding the linked post, but my ultimate question is how can I structure the security system so that the message may be encrypted in the database (in the event that someone gets unauthorized access into the database) without having one person's password being the key to the decryption.

YES YOU CAN.

It is possible to use the same password for authentication and for data encryption. What you need is to derive from the password, using your favourite key derivation function, a sufficiently long password-dependent stream. You then use the first half of the stream for authentication (that's the part you store in the database), and the second half as encryption key.

For the KDF, use for instance PBKDF2, with SHA-256 as internal hash function. Adjust the iteration count so that the computation is tolerably expensive (a high iteration count slows everybody down: your server, and an attacker who would try to guess the password; so make it high). Make sure that you select a new, random, big enough (say 16 bytes) salt for each password (you will store the salt along the hash value in the database). Generate 32 bytes with PBKDF2; use the first 16 bytes as authentication token (stored in the database), and use the other 16 bytes for encryption (with a proper symmetric encryption system, preferably one with integrated integrity check, such as EAX.

If you apply all that and do not botch the implementation, you will be sure that when you will get hacked, it will be the user's fault (e.g. one user will use the name of his dog as password).


Cipher suites vulnerable to logjam The following is a list of ciphers, how to know which ciphers are vulnerable to LogJam attack?

Client shared list of ciphers:

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Server chosen cipher: TLS_RSA_WITH_AES_128_CBC_SHA

Any with _DHE_ in them. Those are the ones that use Ephemeral Diffie-Hellman, _ECDHE_ is safe.


Why unsupervised anomaly-based intrustion detection training data should be normal or less noisy I recently read a paper which stated that "Traditional anomaly detection algorithms require a set of purely normal data from which they train their model" [1]. But as in K-means, or other unsupervised clustering algorithms, what does this mean? How they work if there is only one cluster? Their point is that they can cluster different unlabeled data classes.

Another paper says that there are two assumption in unsupervised techniques: 1. there should be much more normal traffic than attack traffic, and 2. attack traffic should be different than normal traffic [2]. Why? K-means can separate two sets of the same number of elements.

References:

[1] Page 2 of "Intrusion detection with unlabeled data using clustering", Leonid Portnoey, Eleazar Eskin, Sal Stolfo, DMSA 2001.

[2] Section 3.3 of Jose F. Nieves, "Data Clustering for Anomaly Detection in Network Intrusion Detection", Research Alliance in Math and Science, 2009.

This is a puzzling question.  The explanation is provided right there in the paper, in some cases right near the quotations you provided.  Perhaps it is worth re-reading the papers through a second time, as it sounds like you might have missed a few details on the first pass.
On the first quotation ("traditional anomaly detection algorithms require..."):

Well, that's just how traditional anomaly detection algorithms work.  Those algorithms work by starting with a training set of normal traffic, and then they use the training set to build a model of what normal traffic looks like.  For this to work right, you need a large collection of normal traffic.  As the paper states in the very next sentence, "if the data contains some intrusions buried within the training data, the algorithm may not detect future instances of these attacks because it will assume that they are normal".  If you want more details on how those sort of algorithms work, then your best bet might be to read some papers that provide examples of algorithms of this form.

On the second quotation (assumptions in unsupervised techniques):

I think it's obvious why we need to assume that attack traffic looks different from normal traffic.  If they looked the same, we'd have no way to detect attack traffic.

As far as why the unsupervised technique of Nieves needs legitimate traffic to be a lot more common than attack traffic: this is explained in Section 4.4 of the paper.  It's because the paper assumes that small clusters represent attack traffic.  Without this assumption, it's not clear how we could tell which of the traffic in our training set was normal and which was attack traffic, without labels.  Remember, the paper assumes we have a training set with a lot of traffic, containing a mixture of both normal and attack traffic, and we don't have any labels to tell of us which of the data in the training set is normal and which is malicious.
As the paper explains, "Based on our assumption that a real network contains many more normal connections than attacks, [we consider] the smaller clusters to contain attacks and the bigger clusters [...] to contain normal or good connections" (slight adjustments to grammar to make it clearer).  In other words, that's just how Nieves' proposal works.  Of course there's nothing that says this is the only possible way to do intrusion detection -- but it gives some explanation why Nieves chose to try out the particular scheme he did.

My earlier answer:
It's hard to know without context (you should've provided a link or citation to the specific paper you're referring to).  Without that, we can only guess.
They might be referring to the difference between supervised learning and unsupervised learning.  In supervised learning, we assume that we have a large training set containing many packets, and every packet is labeled as either 'malicious' or 'legit'.
In unsupervised learning, we assume we have a large data set containing many packets, but none of them are labeled.  If you don't have labels for the training data, about all you can do is cluster the data into one or more clusters.
Finally, there's one more situation that is common for anomaly-based IDS's: we are given a large training set containing many packets, and it is assumed that everything in this training set is legit (non-malicious) and representative of normal non-malicious traffic.  Then, one can try to build a model of what normal traffic looks like; during operation, if you see any packet that deviates from the model, then it might be an attack.  This is the basic concept of anomaly detection.  There are many ways to build a model of normal traffic, but one possibility is to use clustering (e.g., K-means) to cluster the normal traffic into one or more clusters; during operation, any packet in or near one of those clusters is assumed to be normal, non-malicious traffic.  If this is what's going on, you can see that this works even if there is only one cluster.
If I had to make a guess, my guess would be on the latter explanation.  But without a paper citation, it's hard to say for certain.
P.S.  No matter what technique is used, you can hopefully see why it is important that anomalies (i.e., malicious traffic) differs from normal traffic.  If malicious traffic looked the same as normal traffic, you'd have no hope of detecting it.  And, indeed, the entire definition of an anomaly is "something that's different from normal", so for anomaly detection to be useful at detecting attacks, we have to assume that malicious traffic is anomalous (different from normal traffic).


Can you defeat evil twins using public and private keys? I came across evil twins which to my understanding are malicious WiFi networks broadcasting the same Ids as other legitimate ones. People then unknowingly automatically connect and are at risk.

I understand you can avoid this by simply not allowing your device to automatically connect, but in theory could you use the same idea that public and private keys allow you to send messages securely that are ensured to be from who they say they are to connect only to the WiFi networks that you want?

In addition if that is a possibility, is it already implemented or is it a case of doing too much when other controls like not allowing automatic connection are already available?

If you configure wireless access points for mutual authentication, regular users will not automatically connect to unknown networks.

The easiest way these days is probably EAP-TLS (basically everyone supports it). Note that the user's machine must trust the certificate from the access point, so a one-time setup will be necessary which places your CA certs into their OS trusted store. Obviously, this only works in enterprise scenarios where you've deployed certificates to network devices.

For open public wifi, there is no solution. As MTG mentioned, you simply use TLS to secure your communication. The network will be able to see where the packets are going, but your data will remain confidential.


Digital Certificate deployment: using two certs for each user? At a large enterprise environment I have come across a deployment approach for Digital Certificates where each user is issued two (2) key pairs:

One for signing documents, emails, etc. that is completely "personal" (perhaps kept only by him in an e.g. smart card)

One for encryption. To avoid any situations of user unavailability, blackmail etc. encryption by this latter key pair can be circumvented by the key management system (using appropriate policies etc.)

This approach is supposed to safeguard from an administrator signing as a user but I find certain usage scenarios making things complicated. E.g. how about sending signed and encrypted emails? Two public keys maintained for each user in the contact list?

So, is this an overall preferred (and widely used) design? Or should we just use it in certain cases where prevention of impersonation is the highest priority?

In a sane organization, it is actually necessary to have two distinct keys, one for signing and one for encryption.

When you receive some encrypted data (e.g. an encrypted email, as in S/MIME or PGP), you normally store the encrypted data (that's what happens by default for email). Therefore, if your private key becomes "unavailable", you cease to be able to read previously stored data: this is a data loss situation. "Unavailability" of the private key can take multiple forms, including hardware failure (your dog chew your smartcard to death) or "hardware" failure (the key holder is hit by a bus, or unceremoniously fired, and his successor should be able to read previously received business emails). To remove the risk of data loss through key loss, a backup of the private key must be stored somewhere (e.g. printed on a paper, in a safe)(this is often called escrow). In short words: encryption keys MUST be escrowed.

Loss of a signature private key does not imply any kind of data loss. Signatures which where previously generated keep on being verifiable. Recovering after a signature key loss involves getting a new key, and that's all. So there is no strong need for key backup here. On the other hand, signatures are normally meant to have legal value (there is little point in requesting a signature if you cannot use it against the signer, should he later on fail to follow on his promises). The legal value is conditional to the impossibility for any other individual than the key owner to generate a signature; this does not mix well at all with an escrow on the key. Hence, a signature key MUST NOT be escrowed.

Since a key cannot be both escrowed and non-escrowed simultaneously, you need two keys.


Are VPNS vulnerable to active man in the middle attacks? I know that with SSL/TLS, man in the middle attacks are not possible. For example if Alice and Bob are trying to communicate and Trudy is trying to perform a man in the middle attack, then when Alice gets the public key from Bob (but really it is Trudy tricking Alice), the public key will not match with the certificate authorities and therefore not work.

I know with SSH, only the first connection to a server is possibly open to an active man in the middle attack. This is because during the first connection, the client records the server's public key in $HOME/ssh/known_hosts file. Every connection after that checks this file to make sure the public keys match.

But how does VPN encryption work with connection set-up? Are certificates used for passing the symmetric keys like in SSL/TLS? If not, does this not make VPNs vulnerable to active man in the middle attacks during key exchanges?

In order to protect from a man-in-the-middle attack, at least one of the endpoints of the communication needs to have some prior knowledge about the other endpoint. It's usually up to the client to verify that it's talking to the right server, because servers tend to allow potentially any client to connect to them. The general term for the kind of infrastructure that provides this prior knowledge is a public-key infrastructure.

In the case of HTTPS, the prior knowledge normally comes with the intermediate step of a certificate authority. A web browser contains a predefined list of CA with their public keys, and accepts a website as genuine if it can demonstrate that its public key has been signed by the private key a CA.

In the case of SSH, the prior knowledge normally comes from having contacted the server previously: the client records the server's public key and refuses to proceed if the server's public key is not the recorded one. (This also exists for HTTPS with certificate pinning.) On the first connection, it's up to the SSH user to verify the public key.

There is no standard followed by VPN software. You need to read the documentation of your VPN software. In enterprise deployments, it is common to either deploy the server certificate to employees' computers alongside the VPN software, or require the employee to make a first connection to the VPN from inside the company network where a MITM attack is not feared. The certificate is then stored in the VPN software configuration and the VPN client will refuse to connect if the server's public key changes.

If you're deploying a VPN service for your own use or for your organization's use, you should take care of provisioning the server certificate at installation time, before you go out in the wild. If a secure network is not available, you'll need to rely on some other communication channel to send the certificate. It could be an email, if that's how you identify users, but it would be best to rely on a pre-existing infrastructure such as GPG keys (send the certificate in a signed email) — which of course only shifts the problem to how to verify the GPG key.

If you're using a cloud-based VPN service, that service should provide you a way to verify their certificate (e.g. a web page served over HTTPS) and should document how to install the certificate or how to verify it on first use. Again, there isn't a single process that all VPN software follow.


Discord server leaking IP addresses I was on Discord, and someone sent me an invite to a server called "Operation: Pridefall".

I didn't know what it was, the link is http://discord.gg/xxxxxxxxx - and the invite was legit.

I thought it was just a regular chat. I looked, and there was some IP addresses being leaked.

I asked the person who invited me, "What is this?". They said "Look it up, it's exposing LGBT people"... I do not hate gays at all, and so they might dox me.

I have changed my discord password. But I don't know what else to do, and if this is legitimate. I do not know if it's possible to hack someone through a Discord
invite.

Please let me know what to do.

Discord itself is entirely server-based, as described in this Discord blog post. In other words, your client is always directly communicating with a Discord server, which then re-sends your data to other clients. That means any potential attacker will see the Discord server's IP and not yours.

However, that doesn't have to be the case for other online services, which you can link in your profile. When you join a server, other users, as well as bots and user-bots, in that server will gain access to the data in your Discord profile, which they can scrape and potentially use to track down your IP. You can see which services you have linked to your account by going to the User Settings and choosing the Connections category.

Your best course of action right now is staying calm. They might try to use the pressure to their advantage and try to direct you to a phishing site to get your Discord credentials or scan a login QR code. By just following an official Discord invite (the https://discord.gg/xxxxxx format), your credentials are safe.

Furthermore, the things you described do violate the Discord's Terms of Service in multitude of ways. You can report the server to Discord's Trust and Safety, as described in this support article.

After you're done with the report (since it requires you to get the server ID, which requires you to be present in the server), or immediately, if you're not planning on making a report, I recommend you to leave the server and report + block anyone trying to threaten/blackmail you afterwards. You're most likely not dealing with a nation-state or an organized crime group, just a group of kids having no better way to entertain themselves during the quarantine, and are safe to ignore their threats. After all, credible online threats can still be subject to prosecution and should things escalate even more, you can report them directly to the authorities.

Lastly, as a general advice, I'd highly recommend enabling two-factor authentication on Discord if you haven't done that already.


Suspicious new folder named .um in internal storage, google search says file is spyware I am running Android 7.0 in a Samsung Galaxy J7 prime phone. Today, while using the phone, I suddenly found a folder named obj in Internal storage/Android, that had never been there before. It had the timestamp of only a few minutes ago. The folder had more files inside, the path is this - Internal storage/Android/obj/.um/sysid.dat

There was a similar duplicate with the same timestamp in the following directory - Internal storage/Android/data/.um/sysid.dat

I did a google search, and a Dr. Web page as well as a Hybrid analysis page came up, both flagging a similar directory as a SMS spy app. The files were same, but the directory was a little different, as they were located on the sd card in the pages, while in my phone they are located in Internal storage and no such files on sd card. Here is the link -
https://vms.drweb.com/virus/?i=15272609&lng=en

I don't know how these files got in, as I haven't installed any new apps in like forever, and also I'm very cautious while browsing, and when these files got created, I was browsing perfectly safe websites. Anyway, since the Dr. Web page had the spyware sample and said it was able to flag the file, I figured the antivirus could at least detect the malware, if not remove it (in case it was rooted in the system), and hence downloaded the Dr. Web Light app from playstore and ran both full and quick scans with it, twice. Did not detect a thing, despite having these file directories explicitly listed on their website analysis of the spyware. I would understand if it did not remove it, but since it has already analysed this malware sample, I would expect it to at least flag the file.

Also ran full scans with Norton, Kaspersky, Sophos, Zelmana and F-secure (all free versions except Norton and Zelamana which gave Premium trial versions), none of them even detected anything.

Apart from the Dr. Web and Hybrid Analysis pages, there is no more information about this on the Internet, except a lonely reddit thread which point back to the same aforementioned pages.

Can anyone guide me in the right direction here? Anyone happen to know about this particular incident? What should I do? Factory reset? Firmware flashing? It will probably take me a couple days to do either because I have to back up personal documents, till then, should I refrain from using the phone? Turn off data connection? Or shut the phone off altogether? Not make any calls or send any sms? I only have this one phone, I'm signed into every which thing from this, and I receive and make calls and messages daily.

I was blindsided by this, so I have to back up my personal files and chats to a USB first, which again, I'm worried, might get infected from being plugged into the phone and later while I restore the backups to the clean phone, causes reinfection.

Any suggestions as to how I can back up safely and what I should actually do at this point to limit any further damage till I wipe the phone?

Please help me out, really worried and still using the phone as I don't have access to anything else. Some detailed information will be very appreciated.

If you only install apps from Google Play, the chances of you picking up a phone virus are slim to none. Google scans all apps added to Google Play for malicious behavior and removes offenders. While some slip through the cracks, you’re very unlikely to install a virus app from the Play Store.

Installing from other sources is entirely different. Downloading apps from random websites, especially “cracked” apps (paid offerings illegally provided for free), is a great way to pick up malware. If you chose to sideload apps, make certain that you trust the location you download them from.
The Play Store is home to dozens of Android virus removal apps. However, most of them are bloated and want you to pay for features you don’t need. However, there are a few worth using.

One of the most trusted names in desktop security, Malwarebytes also provides an Android app.

The free version scans your phone for malware and removes any threats it finds. It also has an audit feature for app permissions, so you can keep track of what each has access to. And it doesn’t have ads either.

However, this doesn’t mean every app on Google Play is beneficial. Scam apps might take your money for nothing, and many free apps abuse phone permissions to steal your data. But those are separate concerns from Android viruses.

Like on other platforms, common sense will help you avoid a virus. Don’t download from shady websites, try to avoid tapping on ads, and keep an eye on app permissions.

  Any suggestions as to how I can back up safely and what I should
  actually do at this point to limit any further damage till I wipe the
  phone?

See this link below:

How to back up your Android phone

Backing up most of your data is actually pretty easy with Google, and it has gotten far easier over the past few years. Unfortunately there isn’t yet a one-stop backup method for Android phones through Google, but there are ways to backup different types of data.
Here’s how to backup your data with Google.
If you’re not already using Google Photos, you should be. The service automatically backs up every photo and video you take to the cloud, so you’ll never have to manually backup your media ever again. If the Photos app isn’t already on your phone, you can download it here. Once it’s installed, you’ll need to make sure Photos is set to automatically backup your files. Here’s how to do that:

Open the Google Photos app
In the menu, head to Settings
Tap ‘Backup & sync’
Make sure the switch is turned on

If you’d like to keep the original quality of your photos, you can, but it will count against your Google Drive storage. Here’s how to check your Google Photos upload quality:

Open the Google Photos app
In the menu, head to Settings
Tap ‘Backup & sync’
Tap ‘Upload size’
Choose the option you’d like

Google Drive lets you store your other files in the cloud, which means they’ll be accessible from any connected device. To manually upload folders and files, follow these instructions:

Download the Google Drive app, if you don’t have it already
In the app, press on the ‘+’ button
Press ‘Upload’
Select the file(s) you’d like to backup
That’s it!

Settings and apps

To backup your phone’s settings and apps, you’ll want to use Android Backup Service. This service essentially backs up the apps you use and the settings that you have selected in most Google apps, making it easy to restore those settings on a new phone. For a complete list of what gets backed up with Android Backup Service, head here. Otherwise, follow the instructions below to activate it:

Open your smartphone’s Settings app
Tap on ‘Backup & reset’
Press ‘Backup account,’ and add your account, if it’s not there already

And that’s it! Your device should be pretty much all backed up now. Unless, of course, you want to use a third party service instead of Google’s own.


I don't see how "-salt" in the openssl command line tool enhances security at all I do this to encrypt a single file:

openssl aes-256-cbc -a -salt -in file.txt -out file.enc

and then type in some regular plaintext password.

I do not understand how -salt enhances the security of this. The reason is that the salt is stored right there in the beginning of the file like this:

Salted__<eight salt bytes>

The salt being available to the cracker in such an obvious manner, what is the purpose of it? I don't see how it would make a dictionary attack harder ... especially given the fact that, as far as I know, openssl only uses one iteration to generate the IV from the password/salt - correct me if I'm wrong.

The point of the salt is to prevent precomputation attacks, such as rainbow tables. Without a salt, anyone could just generate a huge dictionary of hashes and their associated plaintexts, and immediately crack any known hash. With the salt, such a dictionary is useless, since it's infeasible to generate such a dictionary for all possible salts.

I did a pretty in-depth writeup that covers this problem over at How to store salt?, which is worth a read.


Cellular phone cloning It is known that certain methods of authentication are used to tie  a particular device to a particular phone number, so that cloning can be prevented.

What are these authentication mechanisms? Does it have something to do with the International Mobile Equipment Identity?

Usually the mechanism is matching IMEI with the phone number.
However GSM networks, which use a SIM card embedded with the phone number, don't have such a matching mechanism. So you can use the SIM card on different phones, thus phone numbers are not fixed on devices.

Here's a Wikipedia article to explain that.
But, this subject is not relevant to cryptography.

Authentication itself is, of course, achieved by a simple cryptographic function using an authentication key.
This article explains it a bit.


Improving Digest Authentication using PBKDF2 For a variety of reasons, I need to use digest authentication for a REST server that I have created.

I have come up with an "improvement" that I believe strengthens the algorithm against MD5 attacks without being a burden on clients. What problems can you see with my algorithm?

Introduction

Client is a custom application written in C#.
Server is a JAX-RS-based REST Server written in Java and running on Tomcat.
All traffic between the client and server is encrypted using SSL/TLS.
The database contains a user_table with the following columns:

user_id: primary key
password_hash: varchar not null
salt: varchar not null
iteration_count: integer

Digest Authentication (RFC2617)

Digest authentication uses the following calculations:

nonce: server-generated number used once
nonceCount: server-generated increasing value (prevents replay attacks)
cnonce: client-generated number used once
qop: quality of protection ("auth")
method: typically one of "GET", "POST", "PUT", etc.

HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2)

The HA1 value is stored in the database as the password hash value. During authentication, the client calculates the value of response from the WWW-authenticate http headers. The server also calculates the response value using its stored version of HA1 and compares the value received from the client. If they are equal, the client is authenticated.

MD5 is no longer considered secure. Collisions can be found in a few hours using commodity hardware.

Using PBKDF2 to Strengthen Digest

Client obtains the username and plaintext password from the user.
Client requests the salt and iteration count for the user_id from the server. The server also sends the current default iteration count (which may be different than that used for this user).
Client calculates a 128-bit secret key using PBKDF2(password, salt, user-specific iteration count). The secret key is encoded as a hexadecimal string.
Client calculates HA1 using the username, realm, and hexadecimal-encoded key. This HA1 value is used in a standard digest authentication.
Server obtains the password hash from the database. The password hash is the previously calculated HA1 using the same PBKDF2-derived secret key. The server compares the calculated response to the response value sent by the client (standard digest authentication). If the two response values are equal, the client is authenticated.
If the user-specific iteration count returned to the client is different than the default iteration count, the client calculates a new HA1 using PBKDF2 and the new iteration count. The client calls a PUT method on the REST Server to update the password hash column using the new value. This step allows the algorithm to be updated with larger iteration counts as hardware get faster.

The modified algorithm does not rely on the strength of MD5 to protect the password hash, since the difficulty of calculating the password hash is dependent on PBKDF2 (which can use a SHA-1 or SHA-256 hash).

Are there any obvious security flaws in this modified algorithm?

PBKDF2 is a burden. That's the whole point. The thousands of iterations, by design, burn up massive amounts of CPU.

Apart from that, your scheme is indeed an upgrade over plain Digest authentication, but it does not fix everything. In particular, what the server stores (the HA1 value) is "password equivalent": if you know this value, you can use it to connect to the server and play the authentication game. This means that if an attacker hacks into the server and steals a copy of the stored "passwords", then he gains immediate access to all accounts (i.e. the attacker transforms a partial read-only peek at the table, e.g. with a SQL injection attack or a mislaid backup tape, into a complete read-write access). That's usually considered as bad. Plain digest authentication already has this problem, because the server must store the password "as is". Your use of PBKDF2 does not fix that.

In any case, I hope that you play this protocol within SSL (HTTPS), because otherwise your connections can just be hijacked. And if you do play the protocol within SSL, then you can use Basic authentication, which will be even simpler for clients, and allows the server to apply PBKDF2 itself, and store the resulting hash which is not password equivalent.


Types of firewalls to implement to reduce DoS attacks in POS systems Would you need an internal, external and a host-resident firewall for each POS client?

You have multiple areas of concern with DOS/DDOS attacks. If they are external they can fill up the "pipe" in your ISP before they ever reach you. That means that nothing on the inside (internal firewalls, layer 7, blackholes) will prevent packet loss before you even are reached. In order to mitigate this you need to contact your ISP and they will have protections (Kona being Akamai's; there are others).

Internally, a layer 7 firewall should have protections against this. Most layer 7's work with "DPI" and "stateful" detection which means that if you're getting a packet that doesn't make sense for the communication flow, it will be blocked. It will also cut connections for slow loris and other common attacks.

How does your small subnet use the internet? What are you required to allow in? Can you set this up in "proxy half open" which means that anything is allowed out to start a connection, but all incoming connection requests are blocked? That alone should solve this problem so long as the packet flood isn't more than your ISP "pipeline."


What is a good rebuttal to users who wish all data WITHIN Db be encrypted? I am building an application in VB.NET (WinForms) utilizing SQL Server 2008 R2 as a Backend.

The application is to track employee's money they defer each paycheck, or month, to deposit into separate 'fund' accounts. (Think of it like putting $200 of your weekly check into a few different stocks).

The business side says "ALL DATA MUST BE ENCRYPTED!" which makes no sense to me, and makes basic queries (Especially for dates) unusable. That makes the utilization of a RDMS futile.

The only fields I would deem necessary to encrypt would be:

Employee Information (Name, DOB, Hire Date, Address, etc.)
Employee Beneficiary Information (Name, SSN Address)
Account Number for in-house that could be tied back to an employee via payroll

Nothing else encrypted (In my opinion) does not deem these people's information at risk.

What can I tell business users to actually make them hear me out and believe me? These are executives / officers within the company, so a respectful tone would be appreciated!

*Edit:*The information is to be encrypted so DBA's cannot see it, even if they have access to it. I've already tried to bring up TDE. It is not an option.

See what you have there is a solution looking for a problem.

You should start by asking the business what problem is it they are actually trying to solve.  you most likely want to frame the response in terms of CIA (Confidentiality, Integrity, Availability).

If you are feeling really brave try to get the business to perform a threat model on the system, you may find that data confidentiality is not necessarily your biggest risk.

Once you have that information you can come up with real mitigations to the real problem that do not necessarily include encrypting the whole database.  e.g. for confidentiality you can use good authorisation/access control lists.  For data integrity you can consider using data hashes or MACs (you would also want to consider strong auditing to see who is using/changing the data).  For Availability you are looking at typical IT solutions for this, data backup and restoration, server redundancies etc.


Dangers of robots.txt? During a recent scan of my website, a robots.txt file was found and in it contains

Disallow: /subsite1/
Disallow: /subsite2/

In order not to show any paths in robots.txt, as I am afraid that hackers can try to hack the disallowed directories, what can I do to secure robots.txt and at the same time allowing search engines to use it for legitimate purposes?

Robots.txt is not, in any way, supposed to secure your site. The only purpose of the robots.txt file is to inform polite search engine bots what areas do not contain interesting information.

If you have sensitive areas in your robots.txt file, then you seriously need to review the architecture of your site. No sensitive directories should ever be accessible to the public in any way. In fact, anything exposed to the public should be secured, whether it is visible or not.


Is it possible to use Kerberos for SSO in a SaaS application? If I have a webapplication in my internal Microsoft Windows network I'm aware that I can use the kerberos protocol to make a Single Sign on (SSO) into this application with the web browser.

Is it a good idea to use kerberos for SSO in an external hosted and run (think SaaS) webapplication when all clients of this application are inside the same MS Windows Network?

Kerberos uses symmetric keys to sign its tickets. Is this key used for the full Realm or only for a service? My fear is that I have to share a symmetric key with the external hosted application and that this key could be malicious used to authenticate as a user to yet another application. Is there any foundation to this fear or could this be safe?

The way Kerberos works is by the client (browser, app, PC, etc.) requesting a ticket from the KDC (domain controller) whenever it needs to log in to the SaaS application. The KDC creates the ticket and encrypts it to a key only the service knows. Therefore this means the client must have line of sight to that KDC whenever it needs to log in. Within a corporate network this is completely reasonable and is how many apps have functioned for the last 20 years.

However, what happens if the client doesn't have line of sight, say working from home because of a pandemic? In that case the client needs VPN or a KDC proxy to fulfill the requirement. Not unreasonable, but more infrastructure to deploy. Comparatively things like cloud identity providers don't really have this issue (though introduce their own).

Regarding the security of the symmetric key... Only the KDC and the service should have knowledge of that key, so therefore only the KDC or the service can generate a ticket representing the user. The KDC is authoritative so it's going to issue a ticket one way or another and the service is the thing requiring the identity so who cares if it impersonates something only it cares about? Repudiation might be important on that one for the sake of auditing, though you could argue that if the KDC didn't log a ticket creation did it really happen? Also, in Windows-land domain controllers sign an internal bit of the ticket with a key only the KDC knows so with enough auditing it's possible to prove one way or another if the KDC issued the ticket.

Since only the service knows that secret, the best it could do is potentially authenticate itself to the KDC and from there request a ticket to another service, but it's going to be the identity of the service so it can't impersonate other users. Unless you enable full unconstrained delegation. Just don't do that. A SaaS should never need that.


What are the security issues with "eval()" in JavaScript? Every time that someone mentions eval(), everyone says that there are "security issues" with it, but nobody ever goes into detail about what they are. Most modern browsers seem to be able to debug eval() just as well as normal code, and people's claims of a performance decrease are dubious/browser dependent.

So, what are the issues, if any, associated with eval()? I haven't been able to come up with anything that could be exploited with eval() in JavaScript. (I do see issues with eval()'ing code on the server, but client-side eval() seems to be safe.)

eval() executes a string of characters as code. You use eval() precisely because the string contents are not known in advance, or even generated server-side; basically, you need eval() because the JavaScript itself will generate the string from data which is available only dynamically, in the client.

Thus, eval() makes sense in situations where the JavaScript code will generate code. This is not intrinsically evil, but it is hard to do securely. Programming languages are designed to allow a human being to write instructions that a computer understands; to that effect, any language is full of small quirks and special behaviours that are supposed to help the human programmer (e.g. the automatic adding of ';' at the end of some statements in JavaScript). This is all nice and dandy for "normal" programming; but when you generate code from another program, based on data which may be potentially hostile (e.g. string excerpt from other site users), then you have to, as the developer for the code generator, know about all these quirks, and prevent hostile data to exploit them in damaging ways.

In that sense, code generators (and thus eval()) incur the same conceptual issues as raw SQL and its consequence, SQL injection attacks. Assembling at runtime an SQL request from externally provided parameters can be done securely, but this requires minding an awful lot of details, so the usual advice is not to do that. This relates to the usual conundrum of security, i.e. that it is not testable: you can test whether some piece of code works properly on correct data, but not that it never works improperly on incorrect data. Similarly, using eval() securely is possible, but it is so hard in practice that it is discouraged.

All of this is said in all generality. In your specific context, eval() might be safe. However, it takes some effort to have a context safe for use of eval(), that actually needs eval().


Is the fact that Tor's development is largely government funded cause for concern? In light of recent events, I've been learning more about Tor, and I have a lot of questions. Here's one.

Wikipedia's article states;

  As of 2012, 80% of the Tor Project's $2M annual budget comes from the United States government, with the Swedish government and other organizations providing the rest, including NGOs and thousands of individual sponsors.

I realize that Tor software is open source, so surely if there were some obvious issues with it, we'd know about them already. Still, I can't help but wonder if, by using it, I'm simply bringing myself into a henhouse of the foxes' own making, or at the very least inviting more scrutiny. Is my paranoia justified?

Since the source code is open, it can be vetted.  The bigger problem is that a large number of compromised nodes makes it easier to try to track, but this has nothing directly to do with the development itself.  As for why the government would fund something like this.  While it does make it easier for bad people to do bad things, it also makes it easier for good people to do good things in bad countries and that's still something the US government generally likes to see happen.  The technology enables a much higher level of freedom in countries that otherwise would restrict freedom.  While it can make it harder to stop bad people, it still has enough benefit for good that it is worth the risk of bad people abusing it.

That all said, can we be sure that they don't have some way to get around it.  No, but based on the amount of research the government has been known to do on how to try to break Tor, it does seem unlikely they have some magic switch.


A file that doesn't allow copy/paste or print We know that Adobe pdf's convenient control features for discouraging copy/paste and print are not real security measures.

We are searching for a way to create a file that has default security set for preventing copy/paste/print.  We don't care who gets the file, we want everyone who receives the file to be able to open it, but also prevent them from copy/paste/printing the document.

There are companies that can do this with links back to a website, but not with an actual file.  There's the rub.

Does this not exist today?

EDIT:  Clarification - we know these requirements would not make a completely secure document, we just want something with a slightly higher level of security than what we have with pdf.  Trade-offs are having to be made, security level vs ease of use. Thanks.

Nope, and it can't exist in the general case, because you don't control the client device. This is essentially the problem that DRM solutions try to solve for video and audio content, and text or static image content is much less difficult to copy.

For example, if I can see the contents of the file, I can take a screenshot of that content, run it through an OCR package, and I've got the text. I can do that even if you require a special viewer application which tries to detect screenshotting, by using a high resolution camera, such as the one on my mobile phone. You can encrypt the data at rest, but if you want me to be able to see it, I can copy it once it's no longer encrypted, at the point where I'm looking at it. For text, I could just copy it by hand, too...


How safe is opening any website on new browser tab? When I do online shopping where I use my credit card information to purchase, I clear the browser cache, cookies and only open that single site. After I am done, I again clear the cache, cookies and start with my regular browsing. I do this to ensure any other websites that I open on a new tab do not sneak into my credit card information. Is this even possible or just a myth?
So if I wish to open "any" site on a new tab while doing my online shopping, is it safe or do I have to clear cookies every time and open only one site?

So if I wish to open "any" site on a new tab while doing my online shopping, is it safe

The same origin policy should prevent other sites from accessing your data in the online shopping site. That is assuming that the shopping site has no vulnerabilities that leak data (CSRF, XSS, XSSI, broken CORS, broken messaging, etc.).
Having only one tab open may mitigate some of the damage malicious sites could do. But with technology like serviceworkers, malicious sites may also be able to perform attacks even after you closed the tab. If you want additional security, you should use other mechanisms which are designed to separate different areas (e.g. private/incognito tabs/windows, different browsers, Chrome's browser profiles, or Firefox's multi-account containers).


Firewalk through a Firewall on our subnet Having trouble firewalking. I am trying to determine all the open ports on my firewall/gateway. Here is my lab network diagram:

(Skip to the bottom of the following explanation for a direct list of my questions)

Configuration Details:

Firewall is an ASA 5505 with static routes.
The firewall will respond to ICMP echo requests at 192.168.1.2.
The firewall has TCP port 31337 left intentionally open so that we can detect it as part of the exercise.
The "Host" at 192.168.1.4 is acting as the "attacker" trying to determine the open ports.
The "Attacker" is running Kali linux.
The "Target" host is running Windows Web Server 2008 (not sure that matters).

Attempted Methods:

I have tried both the "Firewalk" tool by Packetfactory and also the Nmap firewalk script. Here are examples of the syntax I am using:

Nmap: nmap --traceroute --script=firewalk --script-args=firewalk.max-probed-ports=-1 192.168.3.11

CORRECT SYNTAX FOR NMAP: (solved this!) nmap --traceroute --script=firewalk 192.168.3.11 -p1-65535

NMAP only scans common ports by default. The full port range must be specified.

I simply needed to add the nmap port scan switches in as those are not arguments that can be passed into the firewalk script. I'm still learning...

Firewalk: firewalk 192.168.1.2 192.168.3.11

Current Results of firewalking methods:

Nmap (This list is incomplete but shouldn't be - port 31337 has been opened intentionally on this firewall)

 Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-17 11:15 EDT
 Nmap scan report for 192.168.3.11
 Host is up (0.0026s latency).
 Not shown: 987 closed ports
 PORT      STATE    SERVICE
 80/tcp    open     http
 111/tcp   filtered rpcbind
 135/tcp   filtered msrpc
 139/tcp   filtered netbios-ssn
 445/tcp   filtered microsoft-ds
 1720/tcp  filtered H.323/Q.931
 2000/tcp  filtered cisco-sccp
 5060/tcp  filtered sip
 49152/tcp filtered unknown
 49153/tcp filtered unknown
 49154/tcp filtered unknown
 49155/tcp filtered unknown
 49156/tcp filtered unknown

 Host script results:
 | firewalk:
 | HOP  HOST          PROTOCOL  BLOCKED PORTS
 |_0    192.168.1.43  tcp       111,135,139,445,1720,2000,5060,49152-49156

 TRACEROUTE (using port 1025/tcp)
 HOP RTT     ADDRESS
 1   3.19 ms 192.168.3.11

Firewalk

 Firewalk 5.0 [gateway ACL scanner]
 Firewalk state initialization completed successfully. UDP-based scan.
 Ramping phase source port: 53, destination port: 33434
 Hotfoot through 192.168.1.2 using 192.168.3.11 as a metric.
 Ramping Phase:
 1 (TTL  1): *no response*
 2 (TTL  2): *no response*
 ...
 25 (TTL 25): *no response*
 Scan aborted: hopcount exceeded.

Questions:

Why doesn't the "Firewalk" tool ever see the target gateway (firewall at 192.168.1.2)? Nmap appears to be able to.
Why doesn't the Nmap firewalk script show me all the open ports?
How do I configure the Nmap firewalk script arguments to ONLY check the firewall for port 31337 TCP? (figured this out! -p31337 or -p1-65535. Duh - see the corrected syntax above)

P.S. also thanks to "Gliffy" for the awesome online network diagramming tool :)

According to the man page, firewalk looks to need the following flags in order to properly scan when you are one hop from your gateway (as seen in your pretty Gliffy picture).

  firewalk -d 49152 -r 192.168.1.2 192.168.3.11


Shared Office Network Security - VPNs, Firewalls, and systems First, let me premise this post with the fact that I am completely new to network security. I have done a fair bit of reading up, but I am certainly by no means a professional. If anything I say here is wrong or stupid, please, please, correct me.

Anyway, largely because I have enough patience to install a printer driver, and have a VPN set up on my personal computer, I have been selected to set up all of the IT systems at my workplace... We are currently operating in a shared office space. The fact that the password for the wifi provided by the office space is one of the top 5 most-used passwords in 'l33t' format has me greatly worried about the security posture of the office space as a whole, and therefore my company's NETSEC with it. I understand that the high turnover rate in this office space drives the need for a simple password, but to me it is precisely that same high turnover that needs to be taken into account when devising a network security strategy.

So, question 1) Am I right in being worried that this is incredibly insecure? Wouldn't it take 1/10 of a second to get the network password, and then open up a whole host of vectors for attack? I feel as though packet sniffing, and ARP spoofing should be relatively easy to accomplish, even by someone who has little to no experience such as myself.

Some more context to work with: we do not currently have the need for a dedicated server, and probably won't need to for the next two years or so. Due to the size of the company at the moment, and plans for growth, this has been deemed an unnecessary cost. Basically until then, I am hoping to implement a few simple security measures. I would like to install third-party firmware onto a wifi router which would be plugged into the office space's network. I would then use that router to connect to a commercial VPN provider. Our office computers would connect to that router alone.

Question 2) Is this a realistic answer to the insecurity of the office space's wifi network? Am I wrong in believing that this would protect our data from being visible to running something like Wireshark on the LAN?

From my understanding of it, and if I were to do this, we would lose access to the firewall that the office space currently has on their network (I'm not even certain they have one, but that is a gripe for another discussion). Therefore, I would have to ensure that the VPN traffic is protected in that regard. To address this, I want to install a business antivirus software on our IT systems (with an admin console and all that jazz) that has a firewall integrated with it.

Question 3) Bearing in mind the answers to questions 1 and 2, is implementing such a host-based firewall solution from one of these antivirus softwares an intelligent manner of dealing with this problem?

As I mentioned, the size of our company precludes it from having a dedicated server through which activity could be monitored by someone more competent than me. I think we will have to rely on the AV and its firewall, as well as a lot of education on what phishing attempts look like, why we would be implementing these measures, etc.

Question 4) I know this is vague, but what am I forgetting? If you read my long-winded post, you have about as much information as I do - so what else would you do if you were me? Or would you do approach this problem from a totally different angle?

Thank you for your help! And sorry for the novel...

Network attacks where the attacker connects to your wireless network are uncommon.  That doesn't mean they can't happen, just that it shouldn't be the first thing you worry about.

You are better off making sure all your PC software is up to date -- that includes your applications too (don't forget Adobe, Flash, Java, etc).

Host based firewalls are fine.  The biggest risk is that yo are going to download some sort of malware.  Unfortunately, most antivirus software does a poor job of detecting it.

Consider using a service like OpenDNS that will help you stay away from malicious sites.


what prevents sending "$.post" from one domain to another? I have one website in chromium tab, and an other website in another tab,
Im executing single post command in the second website - $.post(...); to the first website.
Originaly its not working (getting: "No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘null’ is therefore not allowed access") ,but if runing chromium with "--disable-web-security --user-data-dir=~/.chrome-tmp " flags it will send the post.
the question is, what exactly changed so after putting those flags the post is sent ?
I first thought that it disabled "same origin policy" but after some reading it seems like it has nothing to do with it.

The --disable-web-security flag will prevent Chromium from enforcing the same-origin policy (SOP), which will allow you to read the response of your cross-origin POST request.

However, do note that the POST request is always sent, regardless of same-origin policy. Anything that takes place on the server for that request will still happen (creating a resource, updating something, etc.) This is what is meant by cross-domain writes are allowed:

  The simplest explanation of SOP is that Origin “A” has the following permissions:

  Read of resources from Origin “B”: Deny
  Write to Origin “B”: Limit
  Execute of resources from Origin “B”: Allow

Source: https://blogs.msdn.microsoft.com/ieinternals/2009/08/28/same-origin-policy-part-1-no-peeking/

More explanation about "limited write" can be found on part 2 of that blog post.

Mozilla's documentation also explains it well, using different terminology. (jQuery's $.post uses XMLHttpRequest)

  The same-origin policy controls interactions between two different origins, such as when you use XMLHttpRequest or an <img> element. These interactions are typically placed in three categories:

  Cross-origin writes are typically allowed. Examples are links, redirects and form submissions. Certain rarely used HTTP requests require preflight.
  Cross-origin embedding is typically allowed. Examples are listed below.
  Cross-origin reads are typically not allowed, but read access is often leaked by embedding. For example you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

Source: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Cross-origin_network_access


Why do IPSec VPN Phases have a lifetime? I was working on a bug with our VPN, and read about VPN Phases 1 and 2, each of which have a lifetime in seconds.  I was investigating to validate if these had anything to do with the bug we had and apparently not, however I'm still curious has to why do these settings exist at all, what's the purpose of these "lifetime" settings for each phases, what if there was no lifetime, or years instead of the default 1 and 8 hours?
I did research the matter of course, but every search result about the phases lifetime has to do with how long they should be, and that the first phase should be smaller than the second phase.  No one explains their purpose.

This is the Security Association (SA) lifetime, and the purpose of it is explained e.g. in RFC 7296, 2.8 on rekeying IKEv2:

IKE, ESP, and AH Security Associations use secret keys that should be
used only for a limited amount of time and to protect a limited amount
of data. This limits the lifetime of the entire Security Association.

If we used the same keys forever, any compromise of the keys would compromise all the data ever encrypted in this tunnel. The SA lifetime puts limits to the time window. IKEv2 also improves this compared to IKEv1:

A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the SA is responsible for
enforcing its own lifetime policy on the SA and rekeying the SA when
necessary. If the two ends have different lifetime policies, the end
with the shorter lifetime will end up always being the one to request
the rekeying.


Using public/private key to validate multiple devices I think this is possible but I'm not sure what it's called. I want to find a standard way of doing this (never roll your own).

I have a public/private key and a number of devices on a network. Using (for example) the serial numbers of the devices I want to use the private key to create a value the devices can then validate with their serial numbers and the public key.

So the process would be:

Customer provides list of device serial numbers.
Use private key to create a value and give this back to the customer.
Customer enters this value on the devices.
Each device can then validate its serial number using the public key.

What is this called and are there any standard ways of doing it?

I would take a quick look at what a digital certificate is here.

The short:

What you are proposing is basic Public Key Infrastructure. In Large Organizations, they may have their own CA as a Trusted source, primarily because it cost money to use a third party to sign a cert for internal use.

If you customers are external to your business, than I highly advise looking at the Third part signing solution.

What you are most likely trying to accomplish is:

Use the Serial Number of the device as a unique identifier. (See Wiki above).
Create a digital cert signed by a CA.
Use this cert for authentication of the device.

This is more commonly refereed to as Certificate-Based Authentication.

The infrastructure to do this a little tedious for smaller organizations, but their both commercial, opensource. I also direct you to this RedHat doc. You may not be using Linux, but they a great job of discussing the bits and pieces.


Are there any web application security standards? Are there any web application security standards that I can use as a baseline for the security related requirements for a web application, web service, and for  applications supported/hosted by third parties?

How is security risk managed for web application and what are the preventive and corrective controls that I should expect to see?

Additionally, how can we provide security compliance for web applications?

From my findings I found that most organizations have developed their own standards/guidelines like

Protecting Web Applications and Users

Am I mistaken in that there is no universal standard?

From what I understand there is no 'universal' standard, however several standards do exist that you can use as a point of reference.

The National Institute of Standards and Technology [NIST] offers Publication 800-53
If you are dealing with healthcare
information there is the HIPAA set of standards
If you keep
credit card information there is the PCI set of standards
Finally there is a more generic OWASP Application Security
Verification Standard

These are just a few I know about. The standards you build for yourself will be dictated by the nature of your application and the information is serves/stores. However the above resources should help you get an idea of what things you might want to keep in mind or work into your own standard.


Challenge: Shellcode with unique bytes Is it possible to have a (small) shellcode with unique bytes only?

So far I noticed the smallest shellcode I can find online is 19 bytes for Linux x86, but it does repeat bytes, especially the "/" from "/bin/sh" and even some opcodes contain repeating bytes.
Noticed a nice trick on x86_64 where you can

mov rax, 0xFF978CD091969DD1 ; garbage at first look
neg rax                     ; rax = /bin/sh

But still some bytes from the opcodes repeat.
Does anyone know a solution for either x86 or x86_64?

Came up with this in the mean time which respects the conditions and is quite short:

mov rbx, 0x68732f6e696221
or r8b, 0xe
add rbx, r8
push rbx
push rsp
pop rdi
mov al, 0x3b
Syscall