Is zinc.io PCI compliant (/does it need to be)?

Disclaimer: I Am Not A QSA; I Am Not A Lawyer

  My question is, if I wanted to offer similar service (i.e. make
  purchases on behalf of consumers with their cc info), must I (/are
  they?) be PCI compliant? Or, is it simply enough to (1) use SSL on my
  site and (2) never write CC info to my DB?

Yes, you would need to be PCI compliant.  You would be transmitting and possibly processing cardholder data on behalf of merchants.  Storage of cardholder data is only one of the three things that are sufficient to put you in scope.

You might be able to do it without PCI compliance anyway.  You might be outside the normal methods of PCI enforcement.  Visa might not care enough to send lawyers.  That being said, I would not advise testing those possibilities at all.

I'll expand upon this by addressing the rest of your question.

Zinc.io appears to meet the PCI definition of a service provider:

  Service Provider: Business entity that is not a payment brand,
  directly involved in the processing, storage, or transmission of
  cardholder data on behalf of another entity.

At the very least they're transmitting cardholder data - they receive it and then send it along to the merchant.  They may or may not be processing it.

They do not show up on the Visa Global Registry of Service Providers.  That may simply mean that they're a Level 2 Service Provider, because "Entities that wish to be on the Global Registry of Service Providers must validate as a Level 1 provider."

(IANAQSA, but the only times I've heard a QSA mention level 2 SPs it was to dismiss them).

I'm assuming that PCI considers the cardholder an "entity" for the purposes of that definition.  If not, that might be an interesting loophole.  Because the really interesting thing is that it's not clear that Zinc is in the PCI enforcement chain:

  Without actually establishing a working relationship with Amazon, Zinc
  has been able to simplify the ordering process down to just one call
  to the API.

Ordinarily, a merchant or service provider would be required to

  12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

but Zinc doesn't work with merchants, or service providers, they inject themselves as a middleman between the customer and the merchant without the merchant's knowledge or consent.  They're not being held responsible to PCI, so they very likely may not be performing the steps necessary to provide mandated protection for customers' card data.

Since they don't list anything about the PCI DSS, or their compliance with it, on their web site, they may very well be working under the assumption that they aren't subject to it - or they may be choosing to ignore it, knowing that the usual leverage used to enforce it can't be used on them (to wit, being dropped by merchants, being dropped by processors/acquirers, or being fined within the context of their PCI relationships).  Or, who knows, they could be carefully doing their SAQ and getting their quarterly ASV scans and not mentioning it...  have you asked them?

Personally, I'd be leery of entrusting them with my card data.  Their TLS configuration doesn't convince me they care deeply about securing it - as of this writing, a B with RC4, SHA-1, weak DH, and a cert signed by StartCom.  Nothing that violates existing PCI requirements, but not indicative of a company that's putting the right focus on security.


How to know when an OpenSSH rekey occured, and how to trigger one?

How do I know when a rekey has happened? Should I check any logs, or any specific output? Running sshd in debug more (-d) does not show me anything related to rekeying.

It is printed only in debug mode, because it should not be a think you should care about. It should work out of the box as it is. But anyway, you can increase log level from your client using:

-vvv switch to your ssh command (DEBUG3)
LogLevel DEBUG3 config option in your ~/.ssh/config
~v escape sequence during your session

  How can I trigger a rekey?

Rekey is handled by configuration option RekeyLimit in both client and server config (even though a bit broken until openssh-7.2). If you set up low value it should rekey more often, but there is no point in doing that.

By hand in session, you can trigger one, by escape sequence ~R. After that (in at least DEBUG log level or -v, you will see a lot of debug messages:

[root@f24 ~]# ~?
Supported escape sequences:
 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~C   - open a command line
 ~R   - request rekey
 ~V/v - decrease/increase verbosity (LogLevel)
 ~^Z  - suspend ssh
 ~#   - list forwarded connections
 ~&   - background ssh (when waiting for connections to terminate)
 ~?   - this message
 ~~   - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

[root@f24 ~]# ~v [LogLevel VERBOSE]
~v [LogLevel DEBUG]
[root@f24 ~]# ~R
debug1: SSH2_MSG_KEXINIT sent
debug1: rekeying in progress
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: rekeying in progress
debug1: rekeying in progress
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:E9HuzpVQJ/5DavNIZhWzJrADNj5Ntw69RJ1obXJtlGo
debug1: set_newkeys: rekeying, input 5156 bytes 167 blocks, output 5864 bytes 0 blocks
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: set_newkeys: rekeying, input 5168 bytes 0 blocks, output 5864 bytes 0 blocks
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received


How do I solve a lot of Failure Audit (529 680) which are appearing in event viewer “Security” tab?

Most likely noone is trying to hack your server. At least not based on the information provided.

There isn't any harm - actually any problem whatsoever - in getting audit failure events on a public facing web facing server. IIS provides a number of authentication mechanisms.

These failures occur when one method is tried (and fails). The next method in the list takes over and it works as it should.

One of my web servers only takes domain authenticated requests. IE always tries unauthenticated first, so I get hundreds of thousands of these events (albeit with different ID numbers since I'm on 2008 R2) a day.

On a related note you should really look at upgrading. Server 2003 is end of life in June 2015 and 2000 is long since dead. Really had to think about what ID numbers you were referring to.


How should I serve untrusted / unsanitized documents (PDF, DOC, XLS) to end users over the web?

It sounds like you are concerned about viewing documents from an untrusted source (e.g., concerned about the risk that a malicious document might exploit a vulnerability in your PDF viewer, or in Word, or the like).  That's a reasonable concern.

If that's the concern, one way to mitigate it is to use Google Docs to view the document.  Google Docs provides the ability to view documents in your web browser.  Google converts the document into HTML on Google's servers, and then sends the HTML to your browser.  Google then takes responsibility for making sure their servers can handle malicious documents safely.  This is a reasonable approach to protecting yourself against malicious documents.

The primary downside is that it may not be a good fit for viewing confidential documents, because you'd have to upload them to Google before you could view them in this way.

An alternative defense is to keep your document viewers fully patched.  I recommend turning on automatic updates for Adobe Reader and Microsoft Office.  This is an alternative way to mitigate the risk.


What is the difference between a server and an appliance for PCI purposes?

Being very general here, a server is generally where you install an OS on commodity hardware (or as a Virtual Machine) whereas an appliance is on proprietary hardware (e.g. physical switch etc).

While you're using each of the systems to mimic what an appliance would do, all five would be considered servers.

In terms of 'commonly affected by malicious software', Windows must have AV installed. You can consider going risk based on the Linux systems using controls such as : minimal system install, extensive hardening, file integrity monitoring (to identify newly introduced software), logging, host-based IDS (such as OSSEC) with alerting, increasing internal vulnerability scan frequency etc.


How should failures by a single user on a simulated phishing email be measured?

I think focusing on the result of an individual phishing attempt is missing the forest for the trees. As a pentester, when presenting the results of a phishing campaign, I try to present the results to clients in the context of their training processes. Users who take improper action on phishing emails were not properly trained by the organization.

However with that in mind, as an internal IT team, I think you should focus on the aggregated results of phishing campaigns over time. After clicking the first time, did the user receive additional phishing training? After receiving that training, did the user click a similar phishing email later (with approximately the same detection difficulty)? I think those aggregate metrics are what matter, because ultimately the results should influence a change in training processes within the organization. Furthermore the policy within the organization should clearly define how tests are conducting and what the repercussions are for repeated failures. (And to go back to your original question, I think repeated failures in this case means failures repeated across multiple campaigns after repeated training, not multiple clicks on a single campaign).


Is it worth it to fuzz Rust-written software?

Rust can't have direct memory issues. That being said, it can have indirect memory issues caused by external libraries.

Much more importantly, fuzzing can expose other types of bugs as well, so it is definitely useful to fuzz the program. Whether it is worth the setup time depends on your use case, but in most cases, it should be.


AMD K8 processors may not be vulnerable to Spectre?

You were right, and now there is some confirmation from AMD.

In this whitepaper that describes possible mitigation techniques, the AMD family 10h (= AMD K10), as well as the AMD family 0Fh (= AMD K8) are mentioned.


Adblock to prevent employees from accidentally clicking malicious ads

Not needed but Its generally a good idea, malwaretising is quite common nowadays, plus most of users will probably appreciate the lack of ads. However, it may not prevent any infections at all if you have other things setup correctly (sandboxing, not using flash and java in browsers etc.)

But instead of forcing users to install them you can use stuff like Firefox ESR with CCK2(http://decentsecurity.com/enterprise/#/ublock-for-firefox-deployment/). Which would be a cleaner options.


Why is it a security risk to use Apple's receipt validation service directly from a device?

The thing is that you shouldn't perform the decision of allowing or disallowing access to content, on the device.

Eg, lets say you have a game, with purchaseable maps.
If you include all the maps with the game and directly communicate with the validation service, someone could simply set up a fake "apple validation server" and have the fake server always return "Purchased" for everything.
And this also means you need to embed the shared secret inside the app, thus it can be decompiled and the shared secret exposed.

However, lets say you now put your own server in the mix. Now, you instead make it so your app on device, contacts your server and ask for a map, sending the receipt as proof of purchase. Your server then uses "apples validation server" to ensure the receipt is genuine, and then returns the map.
If the validation fails, your server simply refuses to supply the map.
You understand now why its much harder to spoof or hack? The owner of the device cannot simply fake the response from your server, since they would need to have the map for that.

This also means the shared secret is stored on your server, and is used to authenticate requests from Apple's server. This is one of the reasons no MITM could put themselves there. Also MITMing a connection between your server and apple's server, is much much harder, than MITMing the connection between THEIR OWN DEVICE and apple's server. Its pretty obvious. Their own device could be just modified to accept the invalid certificates their MITM software generates.

Same here if you run some online game service with purchaseable "coins" or other in-game currency. Then your server will just receive the receipt from their device, and its your server's job to validate this receipt and then add the coins to the user's account.
But if you allow the device to itself validate the receipt and then tell your server "Hey, I purchased some coins and it validated ok with apple", then the device could obviously lie.

Yes, obviously, of course, a hacker could distribute your maps with their own form of fake server software as a form of piracy. Thats why you should implement as much as possible of any app or game logic on the server, and just make the client app as "dumb" as possible, just relaying user input to your server and receiving user output.

What you have failed to understand, is that SSL is not designed to protect any communication if any of the parties is dishonest. This is the same with people thinking that "webshops with SSL won't scam you because they are trusted".
SSL is only designed to protect communication between 2 honest parties, from any dishonest third-party. And if you run validation directly with apples service, one of the parties (user's device) is considered dishonest, and thus the whole security model will fail.


What to include in emails to make them acceptable to email servers?

You're inquiring about email deliverability, which is a big business exactly because it's so hard to get right.
Anti-spam systems key on anything and everything they can to determine what is and is not safe, and it's a cat-and-mouse game with innovations happening on both spam and anti-spam fronts. Rule-abiding bulk email senders tend to get caught in the middle since that's the noise that spammers try to hide in.
First, cover your basics:

DMARC, DKIM, and SPF
FCrDNS in sync (HELO, PTR, no CNAME)
Warm up your sending IP addresses and domains – don't pop up with high volume out of nowhere, ensure your mail relays are known
Monitor your sending IP addresses for presence on DNSBLs (aka blocklists, blacklists)
Try to get your sending IP addresses on allowlists (whitelists) like DNSWL.org
Have special handling to auto-unsubscribe recipients of bounced messages

Learn more at the M³AAWG Sender Best Common Practices paper, authored by a group that coordinates between responsible bulk senders, anti-spam vendors, and bulk receivers
If that's insufficient (which is likely), you need professional help, e.g. from a Email Service Provider.


Differences between using an encrypted container and encrypting a partition

The container is an file, that can reside anywhere. You can copy or move it and the data inside remains secure.

Encrypting the whole partition encrypts all content in that partition. To securely move something from there, you would need move it to another encrypted partition or container.

Performance is pretty much similar in the case of reads/ writes.

In the case of data loss, things get more complicated. Results really depend on the type of damage.

The container file is definitely easier to backup and restore, but has the disadvantage that if you have no backup system whatsoever and you damage the container file, there could be massive damage inside it or it even become unusable.

In the case of full encrypted partition, damage like bad clusters has less impact than it has on a file container, but it presents the disadvantage of total possible failure in case of various critical partition areas damage.

To choose between the two you should consider what data you store there, how large is it, how much of it updates/changes and how do you intent to back it up.


Discovering a vulnerable service on a machine

Thanks guys for your help ! Stranegly I was able to identify what is running on that port just by opening this netcat connection "nc -nvv x.x.x.x 25" and waiting for a while without any interaction with the victim. After doing this, the banner popped up and it was running Sendmail.

It seems that it has been configured to slow the response to prevent automated scanners from identifying what is running on that port.


Is IP address whitelisting useful if the IP address is not “secret”?

But I've read it's fairly easy to spoof IP addresses

This is where you are mistaken. It is easy to connect to a website so it sees an IP address that is not your own by routing through a proxy server, but you cannot spoof an arbitrary IP address. For the TCP protocol, which is in all likelihood what you are using, it is simply impossible to spoof an IP address without compromising a large portion of the very backbone of the internet itself.

The reason for this is that TCP uses a handshake to establish a connection. First, the client sends a SYN packet. The packet contains the source IP. The server then responds to the specified IP with a SYN+ACK packet, after which the client finally sends out an ACK. While it is technically possible to spoof the source IP, it would result in the server sending the SYN+ACK to the spoofed source address which, naturally, wouldn't be expecting it and would refuse the connection. Because traffic can only be sent after the handshake is completed, only genuine source IP addresses will work.

  would IP address whitelisting really add any meaningful layer of security?

If an attacker who has stolen the API keys can only use them to log into your service, then whitelisting your IP does not provide any security improvements. After all, an attacker will connect to the whitelisted address in order to (ab)use the stolen API key anyway. If instead the worry is that the attacker will create a false copy of your site (e.g. an MITM attack) and attempt to get your application to send the API key to them, whitelisting the address will still not help. Instead, you should use TLS for all communications and hardcode the TLS fingerprint in the application. That way, your clients can be ensured that the application will refuse to connect to a non-genuine server.


Computational Feasibility of finding 'Good Links' of the following format

No, I think your math is off.  I do not think this is actually a real vulnerability.   If your description of the format is accurate, and if the numbers generated via a truly random source -- then no, I don't think it is so easy to stumble across other people's pictures.

Let's work the math.  There are 33 random digits in the URL.  That means there are 1033 possible URLs.  Suppose this web site has one billion users (109), and each user posts 1000 pictures (103).  (I'm being generous here.)  Then there would be 1012 pictures posted in all.  This means that accessing a randomly chosen URL would have a 1012/1033 = 1 in 1021.

In other words, you will have to try about one thousand billion billion (1021) times before stumbling on a single picture from someone else.  That would take approximately, oh, forever.

Oh, you want a more precise estimate?  OK, OK, here goes.  Suppose you can make 1000 requests per second (probably a generous estimate, but let's run with it).  Then it would take you 1018 seconds before you stumble across the first picture, with just random guessing.  There are about pi times 107 seconds in a year, so it will take you about 3 * 1010 years before your first success.  That's longer than the known lifetime of the universe.  (By the time you stumble across your first picture, everyone shown in the picture will have been long since dead, and they won't care any more.)

So, no, this attack is not a threat.  As long as the random numbers in the URL are truly random and unpredictable, this scheme is secure.

The biggest risk comes if the numbers in the are not actually truly cryptographically random.  If the numbers are generated using a non-crypto-strength pseudorandom number generator, or via some other predictable sequence, then the scheme could be vulnerable.

Ironically, your example code would is a good example of how not to do it.  You used Python's built-in random generator.  That is not cryptographic-strength, and thus its output is likely to be predictable.  The security is at best as good as the amount of entropy in the seed to the pseudorandom generator.  Even worse, with many such pseudorandom number generators, if you observe a few outputs from the generator, you can predict all following outputs -- which would be deadly to the security of such an image-hosting scheme.

Is your website using a vulnerable pseudorandom number generator?  If they know what they are doing, I sure hope not.  However, you probably have no good way to know for sure from the outside.

To learn more about the subject, I'd like to refer you to two resources: first, Make sure you seed random number generators with enough entropy; and second, this Dilbert cartoon:


Major differences between Snort and Snort 3.0

From the https://www.snort.org/snort3 web page linked to from the page you linked, they list the following:

Support multiple packet processing threads
Shared configuration and attribute table
Use a simple, scriptable configuration
Make key components pluggable
Autodetect services for portless configuration
Support sticky buffers in rules
Autogenerate reference documentation
Provide better cross platform support

Were you looking for more than this?


What practical uses are there for the AD feature of "Confidential Attributes"

I see that Stanford is using it as part of their bitlocker system recovery process Stanford link

  For computers that are part of the Stanford Windows Infrastructure, a copy of the recovery password is stored with the computer object as a confidential attribute. By default, only Domain Administrators can see confidential attributes, no matter what access is granted by standard ACLs.

Looks like a great feature to leverage for Role Based Access Control but I don't have any examples at hand.


How web services collect machine identifiers to track visitors?

I will disagree with John Wu.  There is a lot of information that a website you connect to can gather about your computer from the simple TCP connection performed.

p0f - the first (and still active) passive fingerprinter, analyses details of your connection including:

Order of TCP options (gives away the OS, often the version of the OS)
MTU (gives away the type of connection used: ADSL, PPoP)
TTL (gives away the OS to some extent, and can map your NAT if combined with timestamping, see below).

The README for p0f cites almost a hundred little information disclosure vectors.  But the most important one is TCP timestamping, by which a website you connect to can determine the uptime of the system.

You may think that knowing the uptime of your system is no big deal, but by the contrary.  Several OSes send the TCP timestamp based on their uptime and to the granularity of miliseconds, and, therefore, the timestamp identifies your system very well.  There are not many computers that were booted exactly on the 22nd of October, 2016 at 5PM, 32 minutes and 4.589 seconds.

Of course, the ability to track your machine through passive fingerprinting decreases significantly once you reboot it.  But companies like google are more interested about a browsing session performed, not necessarily your repeating habits day by day.

Extra references

Client Identification Mechanisms - A Janc, M Zalewski


Best practices for sharing or managing passwords between teams

The Best Practice for sharing passwords is DON'T!

Your don't make clear exactly what you are doing, but in general allocation of common resources should use permissions for every user, or class of user if you go that way. Every user should have their own password and permission set.

Corporate access works the same. Corporate has their own set of permissions and passwords.

While there are occasional reasons to share passwords, they are rare. Consider structuring your system to avoid password sharing.


Does a random number after the login name in the public members section of a website increase security or privacy?

If you're wondering why this is done in practice, it generally (to my knowledge) has nothing whatsoever to do with information security. With forum software I'm aware of, the username is actually completely superfluous from the server's point of view; the number is the member ID number, and is all the server looks at. The username is just there so that the URL is more descriptive; it's strictly optional, and can be whatever you want, but by default it makes it clearer what the URL points to. You can see an example on Stack Exchange: your user profile is https://security.stackexchange.com/users/15000/antoine-lecaille but https://security.stackexchange.com/users/15000/cpast or https://security.stackexchange.com/users/15000/not-a-real-user takes you to the exact same page.

Related question on SO: https://stackoverflow.com/questions/16064124/incidentally-se-does-the-same-thing-for-question-urls


How often should an SSH key pair be changed?

I'm going to take a different position from others here.  My recommendation: There's no need to change your SSH private key, unless you have a good reason to change it.

Rationale: Crypto doesn't wear out.  It doesn't become weaker with repeated use.

The biggest reason to change your private key is if you have a reason to suspect it has been compromised or is no longer secure.  For instance, if one of your machines is hacked, and you have a copy of your private key stored on that machine, I'd recommend changing your SSH key.  Similarly, if one of your backups goes walkabout, and it had a copy of your SSH private key on it, I'd recommend changing your SSH key.  Or, if you generated your private key on an old Debian system, then it may be insecure and I'd recommend changing it.  However, if you don't have a reason like that to suspect that your private key is compromised, I see no need to change it.

The downside of changing your key unnecessarily is now you have to update the authorized_keys file on every machine you might ever log into.  That's a bit tedious.

I suspect the reason that some folks are recommending you change your private key is for prophylactic reasons: what if one of the machines storing your private key got hacked, and you were unaware, and now the hacker no longer has access?  The hacker may still have your private key.  Therefore, there may be some value to occasionally changing your SSH private key, to limit the exposure in that kind of scenario.  But personally, I suspect that kind of scenario is very rare and probably not worth the trouble of changing your SSH key.  So, if others prefer to change their SSH keys periodically, I can understand their reasons -- but personally, I wouldn't bother.

P.S. If we were talking about a host key (rather than your personal key), then there is an even stronger reason not to unnecessarily change the host key: if you change the host key, everyone who tries to log into that machine will start getting warnings that they might be under attack.  If people routinely see these warnings, they'll start to treat them as meaningless noise (it'll be a boy-cried-wolf situation), undermining their value.  So, don't routinely change host keys without good reason.


How to handle session absolute lifetime during user activity?

as far as I can tell the OWASP guides don't talk about this

OWASP addresses session timeout and explains the risk:

The Session timeout defines an action window time for a user, this window represents the time in which an attacker can try to steal and
use a existing user session…

If timeout depends on idle duration only, and such token is stolen, then the attacker can first establish refresh process by sending requests regularly to have a valid token at any time. In the meanwhile the attacker can analyze the API better, construct a desired bad request, then executed it. The attacker will have unlimited time for such work.
OWASP suggests following:

Set session timeout to the minimal value possible depending on the    context of the application.
Avoid “infinite” session timeout.

Then, if the token is stolen, the attacker will have limited time to use it.
Too long validity increases the risk of successful attacks. Too short validity makes user experience worse. Only you can decide what risk is acceptable and thus what timeout is acceptable.
Some other thoughts about timeout you can find also here.
How can you implement it? Before you implement your own solution from scratch, consider using some existing solutions. For instance, there are many implementations of Open ID Connect. Implementing your own solution should address many questions. For instance, do you want your application to handle both access to resources and authentication or do you want it to be two separate applications? If you have such kind of questions, ask them as separate posts, because a single post should address a single question.


Virtual machines make no difference here.

Assuming the owner/admin of the wifi access point is a average person, and not the NSA:

If the admin is reading the traffic passing his AP, but not doing anything else, HTTPS connections that are properly configured by the website owners are secure (sadly, as lay person, judging the configuration quality is not possible).
HTTP connections are fully readable by the admin.

If the admin starts to modify traffic passing the AP, as before HTTP connections are not protected from anything. This holds in both directions, ie. what you get from the webserver could be faked, and what the webserver gets from you too.
About HTTPS, pay attention to certificate warnings (instead of clicking the away, if the browser allows it). A warning is no proof for maicious activity, but nonetheless, don't proceed.

Thhird point, stop thinking that your wifi traffic is everything. Being connected to some network controlled by an attacker is very helpful to take over your computer completely...


I don't have the exact specs to hand, however we used to run a very successful wireless honeynet based on freely available sources which we would take to sensitive environments to see whether there were active attackers in the environment, and what they would do.

Core to our setup was a laptop running a honeynet based environment, with simulated traffic between multiple virtual hosts running in VMs to look like finance servers, databases, users etc. Without that emulation of real world traffic an experienced attacker will realise very quickly that they are within a honeynet.

On another laptop, connected by a uni-directional ethernet cable to prevent its visibility to the attacker , was our logging platform. Again, if an attacker spots a logger which is not appropriate for the supposed environment, they will be suspicious.

This honeynet was quite configurable, and although it did take a fair amount of work to set up initially (one of my team created most of it) he said it was pretty straightforward.


Is there a way to securely lockdown a website to an Iphone?

You can use Apache's mod_ssl to authenticate against client certificates.

The example is from cacert.org, but you can create your own CA to accomplish the same goal.


What are common methods to verify symmetric encryption keys?

In practice all symmetric encryption algorithms are just algorithms that scramble data with a key, therefore you will always get some output data, even if you decrypt with the wrong key but will most likely just be random nonsense data.

The standard method is to hash the message with HMAC to get authentication. Most common is to do HMAC over the encrypted message, not the plaintext. Then upon reception you first verify the message and if that was ok, you decrypt it.
Since people have done it wrong by mistake in the past, there are also "packeted" solutions that define how the symmetric cipher and the authentication tag should be created, like AES-CCM, AES-GCM and ChaCha20-Poly1305.


gpg2 always includes the encryption master key to comply with the latest DHS consumer encryption standard.

No, kidding, actually gpg2 always starts an "agent" that holds on to your passphrases for you. Do:

killall -w gpg-agent

And then try to decrypt again - it should ask for the password again.


Is it safe to tell credit card number to bank employee over a phone?

If you consider how credit cards are used there is no increased security risk associated with providing the bank employee with the card number and your name and address.

For example if you use the card for mail order purchases you will provide the same detail, but also the CVV code and expiry date a greater level of risk...but this is how they are intended to be used!

Similarly for any 'in-person' transactions, often the retailer will have full access to all the details from the card, albeit normally without address details.

Given that you are phoning the bank, by implication the person you are providing the details to is trusted by the bank...for the vast majority of subsequent card use scenarios there will not be as much trust in the person you provide the information to.

If the phone call requires you to 'authenticate' using a telephone banking password or phrase of some description, this can help to ensure that someone who has intercepted your post and stolen the newly issued card cannot activate it and use it.


How do I ensure my USB drive isn't infected?

Given that the website in question seems to be related to adware, I highly doubt that the hardware/firmware of your USB drive itself would be targeted. That is a much more elaborate attack than a persistent browser redirect, and may have to be tailored to your specific type of drive.

As mentioned in comments, if you still do not trust it, a new USB drive is not a big investment.


Is it truly possible to store passwords securely, but be able to see the password?

Context is everything.

  storing passwords via encryption is like storing passwords in plain text.

This advice is about client programs implementing a faux password manager that stores password to access online service in encrypted format so you don't have to type the password to access that service at all. This kind of encryption is moot because to allow zero password login, the decrypting key for the password manager itself must be stored along side the encrypted password itself, this gives you no more security than just storing it plain text.

A proper password manager, on the other hand, encrypts your password using a master password (or more commonly, the master password encrypts the master key used to encrypt your data). This is secure because you can't unlock the password manager without the master password. This does mean that you must type the master password every time the password manager throws away the decryption key (e.g. definitely over reboot and when the password manager process is killed and depending on settings, possibly over hibernation, suspend/sleep, or screen off).


Fix vulnerabilities in ALL applications, or only client-facing ones?

Prioritize fixing vulnerabilities based on whether they are exploitable remotely [at least theoretically]. Prioritizing 'front facing' components is not the right approach since there could be serious vulnerabilities on components behind the firewall which could be exploited remotely. For example an XML parser you are using behind the firewall may have a known XXE issue. Firewall may do nothing to prevent it unless it is a WAF and have a specific rule to block that. With your current prioritization you would ignore this vulnerability and it would result in the application being remotely exploitable.


This is an area where you would be best consulting a lawyer for a definitive answer. We can expound on this topic to our hearts content (and I have chosen to do so below) but don't just believe us.

My reading of the Computer Misuse Act is that it does seem to prohibit writing about specific means that can be used to break into a specific computer system. In fact, it is almost certainly this provision which can be used to prosecute those who write malicious software (viruses, worms etc.). However, keep in mind that the Human Rights Act also protects your right to free speech. Which act takes precedent in a certain situation is something a lawyer can explain better than anyone on this site. I would suggest that a document detailing facts is more akin to distributing knowledge and therefore protected by free speech legislation (I'm happy to hear other suggestions).

A lawyer conversant with such things would be able to explain what is meant by "article" in this context. You obviously mean a document stating how to carry out certain procedures (i.e. how to do a port scan) whereas that provision of the act appears to me to be talking as much about programmes or data (for example tailored exploit code or a virus).

It would be analogous to being caught carrying a flick knife or lock picks. They have a specific use, and mostly used for committing crimes (though someone has told me before carrying lock picks is a grey area; IANAL). If you wrote an article "The steps you need to bypass company 's security measures and access their secret database MWAHAHAHA" then you are almost certainly breaking the law. However, an article which merely specified how nmap works in general wouldn't be an issue.


Adding custom embedded Precertificate SCTs into the certificate?

RFC 6962 describes (pretty hidden) that:

  by encoding the SignedCertificateTimestampList
     structure as an ASN.1 OCTET STRING and inserting the resulting data
     in the TBSCertificate as an X.509v3 certificate extension (OID
     1.3.6.1.4.1.11129.2.4.2).

(OID-ref here.)


How to secure SFTP against symlink attack?

The problem is that the symlink looks different in the chrooted environment and from the point of Apache/webserver view.

Unless the symlinks are necessary for the users, the obvious option is to forbid users connecting over sftp to create symlinks. You can do that using a parameter to sftp-server:

internal-sftp -P symlink


The strongest possible way to encrypt data is to start with a threat model.  What sort of adversary are you trying to protect your data from?  What are they willing to do to get it?  All reasonable approaches to cryptography start with one.  If you start with one, you stand a chance of finding "the strongest" for your particular situation.
I recommend this approach because, as you start thinking about threat models and researching them, you'll start to realize that security is far more about the human element.  Then you can worry about things like how you will secure your key.

source: https://xkcd.com/538/
Once you have decided whether you are trying to outwit a state actor while committing treason, or just merely trying to protect your diary from the prying eyes of your little sister, you can decide what the best algorithm is.
Failing that, go with the flow.  Rather than finding out what is the "strongest" encryption, look for what is "recommend" by the security experts for someone who knows nothing of cryptography.  Currently AES comes highly recommended.  We're quite confident that nobody short of a state actor can break it, and we are reasonably confident that no state actor can break it either.
But better yet, don't look for encryption algortihms, look for tried and true packages which are recommended.  The application of an algorithm is as important as the algorithm itself.  Highly reputable implementations are worth their weight in gold.


Why isn't FTPS, SFTP, or other protocols which use SSL/SSH on port 443/22?

Ports are an endpoint for communication and usually represent services running.

I think your professor meant that a service using SSH or SSL would internally interact with the SSH and SSL services running on ports 22 and 443 respectively.

It does not however mean that a service, say HTTP (whose port is 80, usually) runs on 443 when serving with SSL/TLS enabled.

Also, port numbers vary. You can usually run any service on any port that isn't already occupied/reserved.


Communication between SIM, baseband and application processor

I don't know anything about the application processor side, but I can tell you some things about the SIM side:

Subscriber Identity Modules are a type of smart card, and as such they not talk AT, but a separate protocol from ISO, commonly referred to as APDU. The rest of ISO 7816 is mostly innocuous, and doesn't even deal with broadband, which is fortunate because ISO doesn't provide them for free.

Enter 3GPP, which maintains the standards for smartcards connecting to the GSM network. These standards are a superset of ISO 7816 and are freely available at their website (go browse around there for a bit, it's an amazing website teeming with the most detailed information)

In the 11.11 standard, some of your assumptions are confirmed: The SIM does not do A5 encryption, you Mobile Equipment does that, the SIM does A3 and A8.

In the 11.14 standard things get interesting, these are the details of what SIM applications can do with the Mobile Equipment uplink. Turns out they can do just about anything, sometimes on the pinky promise that "It shall be possible for the user to deactivate this command". Voice calls, Data, you name it.

Whether or not the Ki is accessible to SIM applications may hopefully be found somewhere in the 31 series specifications. I haven't had the time to read through all that. 31.130 looks like a good place to start.


Do AES-NI instructions accelerate both AES-128 and AES-256?

Yes, AES-NI accelerates both AES-128 and AES-256, and yes, there is a performance difference between hardware accelerated AES-128 and AES-256, according to https://software.intel.com/en-us/articles/intel-aes-ni-performance-enhancements-hytrust-datacontrol-case-study#_Toc397546813:

  On Ivy Bridge here are the raw numbers for both
  Cyber-Block-Chaining  (CBC) and XEX-based
  tweaked-codebook mode with ciphertext
  stealing (XTS) modes with both 128- and 256-bit keys.

  Note that for XTS mode, only half the key is used,
  so XTS-512 essentially utilizes a 256-bit key.

# Tests are approximate using memory only (no storage IO).
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   581.3 MiB/s  1961.8 MiB/s
     aes-cbc   256b   431.4 MiB/s  1503.1 MiB/s
     aes-xts   256b  1665.6 MiB/s  1642.3 MiB/s
     aes-xts   512b  1318.3 MiB/s  1282.1 MiB/s

  And for Haswell:

# Tests are approximate using memory only (no storage IO).
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   663.8 MiB/s  2486.8 MiB/s
     aes-cbc   256b   493.9 MiB/s  2043.6 MiB/s
     aes-xts   256b  2265.2 MiB/s  2261.1 MiB/s
     aes-xts   512b  1778.0 MiB/s  1778.7 MiB/s

  We made the following observations:

  For CBC encryption, we see a 40% improvement for 128-bit keys over 256-bit keys.
  For XTS encryption, we see a 30% improvement for 256-bit keys over 512-bit keys.
  For CBC decryption, we see a 20% improvement for 128-bit keys over 256-bit keys.
  For XTS decryption, we see a 30% improvement for 256-bit XTS keys over 512-bit keys.

Note that this is raw performance of the AES-NI instruction. In real world, there is disk I/O or network I/O that happens while data is being encrypted/decrypted, which would affect real world performance.

Also, I believe the above numbers are for single core performance, in implementations that uses multiple cores, even AES-256 can easily saturate the entire I/O bandwidth of an SSD and most networks.

As noted here though, making sure you use the right chaining mode for your purpose actually affects throughput much more significantly than the key size.


What is the best practice to store private key, salt and initialization vector in database?

I will answer your question in two parts since you asked it in two parts:

  Question 1:
  Is it secure to store salt and vector in database same table with private key? Currently I encode public and private keys, salt and iv and save as string (data type VARCHAR) in database.

Short answer: Yes, it is secure.

Explanation: It is generally accepted that keeping salt in plain-text alongside the hashed password is secure. This is based off of the logic that if an attacker has the salt and the hash, they still need to utilize a brute force attack to attempt to guess the password used to create the hash. Keeping the salt a secret as well would improve security but so long as the password is reasonably strong, not necessary. For the IV, it is much more complicated and in my opinion out of scope to go into here (and out of my comfort zone to explain) but it is considered secure for the IV to be stored in plain-text next to the cipher-text.

  Question 2:
  Below is current workflow I design. Is this the best practice? I don't want to make too much process that will affect CPU usage.

The workflow appears good to me and is about the same as I would have done, with a few details I think you can improve since you are asking for best practice:

First, your salt is a little bit too short. The issue with this is that with an 8 byte salt even when generated using a crypto-random generator (like you are, which is good) there is the chance of collisions where two or more different users are assigned the same salt value. To mitigate this, the recommendation I follow is a salt length of 256 bits or 32 bytes.
Second piece of advice and I am not sure based on your code if you are already aware, but make sure you never re-use the same IV with the same AES key twice. Due to very fancy cryptanalysis this can create vulnerabilities in the encryption making it breakable. Since the key is being generated from a user password which I will assume is rarely changed, make sure you rotate the IV every time you re-encrypt the private key.
It appears you are only doing 10 000 rounds of hashing at the moment. Although this is not horrible, the golden rule I have always followed is 2^(year-2000) iterations. Since it's 2018, 250 000 hashing iterations or as close to this value as you can get before reaching severe performance issues is the best practice.

Otherwise I think everything looks good, you made a good choice in hashing and public-private key algorithms and were wise to seek help to ensure you did not overlook anything.

Hope it helps!


PCI DSS compliance for storing PAN and PII in multi-tenant environment

The PCI DSS standard does not directly prohibit shared tenant information, so the simplest answer is "yes, that's PCI compliant."  The real answer is "...provided you have sufficient logical controls to prevent tenants from accessing information that isn't theirs."  Do you have an application pen test which demonstrates the table-level identifier information is successfully used to partition access?

This is most closely spelled out in Appendix A "Additional PCI DSS Requirements for Shared Hosting Providers":

A.1 Protect each entity’s (that is merchant, service provider, or
other entity) hosted environment and data

This is just making explicitly clear that the DSS restricts your ability to share PCI info.  It's just as true if you have two tenants in a database as if you have two merchants in a shared hosting facility, but they didn't bother to spell out each shade of grey in detail.

In my experience, PCI cares that controls are in place.  The only people who ask for complete separation from other tenants are... tenants.  Usually big ones, who feel that you exist to provide an application for them.  They would rather ask you to spin up separate infrastructure than trust your ability to create valid logical controls.  It's like a knee-jerk thing with certain large companies.


What are some attacks to consider in a cloud deployment?

I'm not aware of any AWS hypervisor bypasses to date, then again I don't use AWS. Here's an article (admittedly from 2014) talking about the concerns you raise.

https://www.zdnet.com/article/hypervisors-the-clouds-potential-security-achilles-heel/

While the hypervisor doesn't seem like a likely attack vector, there's lots of ways AWS setuos can come under attack here's a pretty good list as well as a real world scenario of AWS vulnerabilities

https://rhinosecuritylabs.com/cloud-security/aws-security-vulnerabilities-perspective/

If an attacker has physical access to the system, it's safe to assume in all but the rarest if cases they can compromise the system in a potentially undetectable way.


I am hoping someone can shed some light on these nmap scan results

The short answer is that open ports should not be alarming IN THE RIGHT CONTEXT. I perform pentests regularly and many of these ports are open for valid purposes. 514 is a little more uncommon, but not altogether unheard of for some applications, like gaming (if your friend games - this was not mentioned in OP) or sending syslogs.

With that being said, the context is important. Having port 80 and 4899 on a desktop, for instance, is a bit out of context - however, I have run some instances of software and used the localhost:80 to use a GUI (nodered, spiceworks inventory, etc). I agree with the comment above that this looks more like a router than a laptop. If the IP scanned ends in .1 or .254, it's almost certainly a router.

The more important question is not what ports are open, but what services and software are running behind them. Port 3389 is for RDP - is this a server that needs RDP, for instance? If not, you certainly want to disable RDP, as that presents an attack surface.

Instead of checking for open ports, use an AV scanner with up to date definitions and signatures. The trouble is that some malware blocks AV installs, so if you have trouble installing it, that would throw up red flags. I highly recommend malwarebytes as a good first step in scanning.

In the meantime, it would not hurt to disable your network adapters until you can run a full scan of your entire disk.


When should I use the word hacker, cracker, or black hat?

In general I'd suggest avoiding use of the word, because it's meaning in general English is completely opposite to the meaning of the original jargon word, which means that sooner or later you're going to confuse or irritate someone.

See the New Hackers Dictionary, for example, specifically sense 8.

(Warning: that's the kind of document you'll get sucked into and spend days reading the whole thing!)

In it's place, I like to use something vague like "attacker" with non-technical people, and to get very precise and say things like "threat actor" when talking to security professionals.


How to use SSL approach at the application level

First off, an important notice:

DO NOT ATTEMPT TO WRITE YOUR OWN CRYPTO! This includes using known cryptographic routines in a way that isn't standard. if you intend to follow the standards, then you should use a library designed 8and maintained) for that specific standard.

That being said, every time you encrypt a file using a public certificate (using, for instance, PGP with public/private key pairs or AS2), you're doing what you're requesting.

The file is encrypted using a random key and a symmetrical cypher and that key is then encrypted using the public key of the recipient. Here is a picture (from wikipedia) that illustrate that process.

This is also valid for S/MIME, EFS, etc.


How should I authenticate my SPA frontend with my API since I´ve got no authentication process in the site?

If your app is entirely client-side... then anyone who uses it can reverse-engineer anything it does.  This is just part of what you get from not operating your own backend.

You're asking for a way to authenticate to the backend without authenticating.  This is not possible.


Why can't spoofed caller ID's be identified?

There are substantial flaws in the way phone routing works that makes this difficult.

Caller ID is specified by the outgoing call and anybody who has control over a phone branch exchange (PBX) can mess with it. (This is a "feature" so e.g. a support center can always have the same callback number as opposed to the number of the associate calling you.) I believe there is some limited ability to traverse the call routing, but that stops as soon as it hits a voice-over-IP provider (VoIP), which effectively provide a screen akin to reputation hijacking (an attacker gets lost in the noise of a shared pool of resources).

I am under the impression most spam calls come from VoIP, but my spam expertise is limited to email.

Happily, at least for the US, STIR/SHAKEN was just adopted, as announced by the Federal Communications Commission in Mandating STIR/SHAKEN to Combat Spoofed Robocalls.

With strict limitations on Caller ID forgery, endpoint anti-spam can then build blacklists of at least VoIP spammers.

From the FCC's news release PDF:

  FCC MANDATES THAT PHONE COMPANIES IMPLEMENT CALLER ID AUTHENTICATION TO COMBAT SPOOFED ROBOCALLS

  Industry-wide Deployment of STIR/SHAKEN Will Yield Substantial Benefits for American Consumers

  WASHINGTON, March 31, 2020—The Federal
  Communications Commission today adopted new rules requiring
  implementation of caller ID authentication using technical standards
  known as “STIR/SHAKEN.”  These rules will further the FCC’s efforts to
  protect consumers against malicious caller ID “spoofing,” which is
  often used during robocall scam campaigns to trick consumers into
  answering their phones.

  …


XVWA PBKDF2 with sha256 and 1000 iteration

You can try to reverse a hash value by trying to brute force it, i.e. run the has function over a list of possible (password) values until you encounter the same output. If this procedure can be successful is dependent on two questions:

How fast can I compute a password hash (or in other words: how many passwords can I try per second)
How complicated is the password (how many password will I have to try before I find the password)

The calculation time is the quotient of those two values. That is why one uses designated password hashing functions which are slow.

While PBKDF2 is designed as a password hashing function, it has a rather dated design and the parameters chosen here (1000 iterations) are not appropriate for modern hardware.

So, assuming the password is not too complicated, you might have a realistic chance to reverse the hash. The standard tools for such an attack are hashcat and john the ripper.


Yes. You definitely can do this, but it would be easier to bruteforce the actual service. For example programmatically generating login requests and send them manually to the authentication service to which the app is communicating.

Bruteforcing login forms of android apps directly would be much slower, but still be possible. You probably need to get higher privileges on the app performing the bruteforce to automate the UI interaction events from another app.


If your malware detection software/anti-virus produces too many false positives, it will flag many useful applications as malware and users will, rightfully, get annoyed. Sooner or later, the users will either turn off or remove the malware protection completely or get used to ignoring and blindly clicking through any warning that the antivirus raises. The result will inevitably be that in the end, even blatantly malicious files will end up being executed by the users.
Yes, false negatives are harmful too, but having a few false negatives is better than detecting every malicious file (which isn't even really possible) but still having every single malware get through just because the user simply ignores the anti-virus. Additionally, in case a file is borderline suspicious, it can be sent to the anti-virus firm for further analysis and so new malware will be detected and its signatures added to the malware detection engine. However, if false positives lead to users turning off the protection, many malicious files will never be detected or will take a much longer time to get detected, confirmed as malicious and added to the signature database.


The "solution" is to thoroughly document your imaging procedure, including pictures, chain of custody, write blockers, and so on, so that if/when someone does call your methodology into question, you can defend it.  Additionally, you should understand what's happening in an SSD so that if someone asks you about the hashes and why they don't match, you can explain clearly and concisely why that is expected behavior, and then fall back on your documented methodology to defend the integrity of your image.

I suppose if you were in a situation where an identical image was absolutely necessary, you could let the drive sit in a write blocker for a few hours and let all the trim/garbage collection activity on the drive finish so that it no longer moves data. Of course, this could destroy any possible deleted data that you may recover - and even then, the hashes still may not match at the end depending on how the SSD behaves.

Dislaimer: IANAL


Upgrading OpenPGP public key on key servers?

This question has a duplicate on Super User, where I also provided an answer. As the question is a better fit here and cross-site duplicates are not allowed, I will simply be repeating it here, extending it a little bit.

There is no way to "upgrade" an OpenPGP key. You will have to create a new one, and you will loose your reputation in the web of trust.

Some people I met decided to stick with a RSA 1024 primary key, but use stronger subkeys instead (which is easily possible without losing your reputation in the web of trust), which comes with secure day-to-day use (for encryption/signing documents with your subkeys), but might enable attackers to add and revoke certifications, subkeys and UIDs.

Think about:

Signing your new key with the old one, so others could follow the signatures
Sending a key transition statement to those that signed your old key; some of them might also sign your new one
Getting your new key signed, ie. go to key signing parties
Revoking the old one after some time
Using a seemingly unnecessary large key as primary key and smaller subkeys for day-to-day usage. You will never need the primary key for anything but signing other keys (which is rare) and others verifying your signatures (cheap anyway).


I'm Trying to Find how to Exploit my SQL Code

Doesn't the truncation SQL injection attack only apply to dynamic/concatenated query constructs?


Anyone having physical access to the server can plug a rogue PCI device in it, e.g. containing the Rakshasa malware which will infect the BIOS thus bypassing any full-disk encryption by logging your key's password (implement a rogue forged SSH server, phishing style). Attacker will then have a complete and remote access to the system, while remaining invisible to the OS because the malware runs in System Management Mode.
Rakshasa was developed by Jonathan Brossard and presented at Defcon 20 and Black Hat and is a sadly powerful framework.

This (capturing the encryption passphrase) is also known as the Evil Maid attack researched by Johanna Rutkoswka at Invisible Labs.

Johanna propose a mitigation through TPM.


Are there any same origin issues (SOP) with TOR?

I haven't actually examined Tor, but theoretically there is no problem with any same-origin policy. I don't easily find any mention of problems occurring in practice, either.

Here's a sketch of the theory. The same-origin policy is tied to three values. First is the Application Layer protocol in the form of the URI protocol scheme such as "http" or such as "https" that combines HTTP with encryption via SSL/TLS. Next is another Application Layer protocol, the domain-name system DNS, in the form of the hostname. Last is one little value from the Transport Layer protocol TCP, specifically the port number. You can use the internet for years without ever noticing that port numbers are in use because most sites use the "well known" port number for each Application Layer protocol. Well known port numbers include port 80 for http and port 443 for https.

In the abstraction called the OSI Model, a Transport Layer protocol carries any Application Layer traffic without either layer caring very much about the details of what goes on in the other layer. In reality TCP doesn't really conform to the OSI Model, but for present purposes it's close enough. Tor works at the level of TCP, a Transport Layer protocol, so that's almost all that we need to say about it.

The client software that makes the connection to a Tor node creates a SOCKS proxy connection. SOCKS is an Application Layer protocol that can carry a Transport Layer protocol, specifically TCP. That really is all that we need to say about it. But I'm going to write more anyway.

Just to bolster our intuition, here's a quick description of what happens next. With the SOCKS proxy connection in place, network client software can send normal TCP traffic over that connection and into the onion-routed network. When TCP traffic enters the onion-routed network, Tor's manual says that Tor negotiates a virtual circuit, a TCP network path that is persistent (in the short term). The virtual circuit permits the normal client software's normal TCP traffic to pass right through, except for the important fact that it gets onion-routing wrapped and unwrapped around it on the way. At the exit node from the onion-routed network, the important ventriloquism effect occurs. It appears to anyone on the far side of the onion-routed network that the Tor user's software is sending and receiving at the exit node.

The recommended Tor client-side software, which is called the Tor Browser Bundle, helps to preserve anonymity by making each Tor user's client-side software practically the same. The bundle provides the NoScript extension for Firefox. This copy of NoScript is explicitly configured not to prevent sites from executing JavaScript in the browser. That gives me extra confidence that JavaScript is expected to work and therefore that there's little or no difficulty with the same-origin policy. JavaScript's same-origin policy (SOP) is actually a little more restrictive than the SOP for other web client features such as cookies and plugins, so I feel confident that they work fine, too.


Reverse Engineer this basic Hash using known answer?

Based on a google search of your hash it's a Dahua hash.Luckily for you it looks like it has some vulnerabilities
www.exploit-db.com/download/29673/ I don't know if they fixed vulnerability and I don't really know much about CCTV systems.If that fails you could try bruteforcing the hash.


There are a number of resources online, but I think you might find that the tutorials about Backtrack might be the most useful. You can run Backtrack on a live cd or as a VM on your laptop. The added benefit to Backtrack is that it will also have the tools to break into whatever host has the flag you are looking for.

Most tutorials will show you how to use aircrack-ng, so getting to know that tool will get you a long way.

Good luck on the exercise!


how may I see if a .iso file is original (to avoid security troubles)?

Is enough to go under Control Panel\All Control Panel Items\System and check for last tab: Windows activation.

Here you should see if your windows is activated, the product ID/key and if your Microsoft software is genuine.

LE: My bad, now I see below asking also about trust and checking if any malware. In this case only a md5/hash compare between your .iso and the original one should help


What is a device that scans the network it is connected to called?

I know a few like:

Pwn Pro
Secpoint Penetrator

But I don't know the exact generic name of those devices and I don't think there is one.


Why is a password saved putty private key 48byte and a non password protected private key 36byte of length

Password protected private keys are simply private keys that are encrypted using symmetric encryption (e.g. AES), with a key that is derived from the password (e.g. PBKDF2).
AES works in blocks of 16 bytes.  Being that your underlying plaintext (i.e. the private key) is 36 blocks in length, it must be padded up to a length that is a multiple of 16 bytes.  That could be one of the reasons for the additional 12 bytes that you are seeing.
Also, key derivation functions usually utilizes a random salt, to mitigate against dictionary attacks.  The salt is not a secret, so it is generally stored along with the ciphertext.  So, another possibility is that some or all the additional bytes are used to store the salt used in the key derivation function.


I just noticed that Teamviewer Host was installed on my computer on 5/4/17 without our knowledge. what does that mean?

TeamViewer is a program that provides remote access functionality, and often has a range of legitimate uses. However, it is also commonly used in a range cyber crime activity.

An attacker may have installed TeamViewer onto your machine either by using other malware, or persuading another user to install it themselves through social engineering. They may then attempt to access your machine through TeamViewer, and potentially install malware, search for financial information, or perform other malicious actions.

I recommend you check the TeamViewer logs to see if anyone logged into your machine using it. Then, you should uninstall TeamViewer if you do not require the software, and scan your computer for malware.

See here for an example of a 2016 scam affecting customers of the UK telecommunications provider TalkTalk, which used TeamViewer.


GWT - using burp suite for injecting xss payloads

Since Burp is acting as a proxy, and since your XSS exercise happens client-side only, Burp will not be of any use as far as I know (since it is not a DOM manipulator, for example).

If you want to involve Burp in your resting, and since it is acting as a proxy, you have to adapt your code so that an http request can be captured and replayed (and for which parameters can be fuzzed).

I'd recommend you to have a form that submits a request with a "payload" parameter, and to fill the content of your DOM via an event handler. By doing so, you would be able to use Burp's features, including the fuzzing of the "payload" parameter


What version did WordPress stop using MD5?

The easiest way to find these things is often to check the source.

If you go to the GitHub repo and search for the password hashing implementation you'll find it in wp-includes/pluggable.php. Then it's just a matter of looking back through history to find the commit that made the change. The oldest version that commit is tagged with is 2.5.

This is further confirmed by checking the release notes for that version:

  Salted passwords — we now use the phpass library to stretch and salt all passwords stored in the database, which makes brute-forcing them impractical.


It is possible that some software that you might have gotten from the torrents or another pirated source installed that certificate onto your computer. It is not impossible since you would be providing your root password during installations.

Yes, it is possible that you installed it unknowingly. But no, without having "always trust" set, it would ask you for authorisation every time, or so it should!

I doubt it is possible to figure out when the cert was installed.


Safe to switch from PBKDF2 to SHA-1 for token verification?

PBKDF2 is a "password-based key derivation function", as its name suggests it. It is intended to make harder to bruteforce passwords with low entropy. When using a source with at least 128 bits of entropy, there is no need to use a PBKDF to strengthen it, because bruteforcing a hash will need, in average, at least (2^127)/n iterations ("n" being the number of users of your system). Using 32 bytes (256 bits) would be safe even with billions of users using billions of accounts.

You will be fine using one iteration of sha256 on a token of 32 bytes generated by a CSPRNG.


User login failure - valid error messages

Yes, email enumeration could be seen as a security risk.

An attacker now knows the email of a valid account and may leverage this to try logging in with passwords from previous breaches.

It could also be used to potentially Phish users of your service.

This isn't a terrible risk though and it can be mitigated by limiting login attempts from a single (or similar IP range). You could also track overall rate of failed logins to detect more advanced enumeration attempts.

There's a number of potential pitfalls related to authentication. OWASP has a great cheatsheet on Authentication, I always recommend it as a first step to checking all your bases are covered.


Is it worth notifying companies about reflected XSS that gets filtered by the XSS auditor?

New bypasses for the xss auditor are found on a regular basis, and there are browsers like FireFox, which still lack a built-in XSS auditor. Reflective XSS needs to be fixed because it is a weakness in the operation of the application.  Relying upon a 3rd party security system is... shaky at best.

When XSS is common place,  other vulnerabilities follow.


I verified that whenever Google chrome browser is launched, it generates series of such random queries (around 6-9) which is forcing the DNS server to return NXDOMAIN response. The link in the question helped me to verify the chrome behavior.


Simply put, you want to maximize the amount of entropy for a given length of data, when doing most cryptographic tasks.

You have (at most) 16 bytes of entropy in your GUID - probably less (some of the bits are deterministic), but we can ignore that detail for the current discussion. When using the GUID's byte[] representation as a salt, you have 16 bytes of data. That's at most 16 bytes of entropy / 16 bytes of data = 1 byte of entropy per byte of data, assuming a completely random GUID. Now assume that you use the string representation. That's 36 bytes of data, but still at most 16 bytes of entropy. That results in less than half the entropy per byte of data (about a 0.44 entropy/data ratio compared to the compact byte[]), which is problematic for some hashing algorithms.

When might this come up?

To take a contrived example (just off the top of my head - I would not actually recommend doing this), consider bcrypt. bcrypt is a password hashing algorithm which, for technical reasons, limits the password to 72 bytes. It does include its own salt, but let's suppose for the sake of argument that you don't trust its salt (again, this is not advice, just an example).

So, you decide to prefix the user's password with a GUID, before feeding it into bcrypt. If you've used the byte[] version, that shortens the effective upper limit on password length by 16 bytes. So, the user can supply a 56 byte password, at most. That's fine - that's still more than 50 ASCII characters, which is a common length people use when they've got a password manager and are a bit paranoid.

Now, let's suppose you had used the string version instead. You've still got the same amount of entropy, but now, you eat up 36 bytes that the user could have been using to pad out their password. They're now stuck with a 36 byte password at most.

And that's just an example off the top of my head; I'm sure there are other cases where using the string version would hurt you.


You are wrong.  It still shows up in the event logs and the computer knows if it is an RDP session.  You can see that there is an active RDP connection if you have the right tools up as well.  What you are talking about isn't an "invisible user", it's a service user, and it is an intentionally designed feature of Windows, not a security hole.  You just aren't familiar enough about working with them and where they are logged.  Service users actually make Windows more secure because they allow automated processes to be configured with the least permissions they need without compromising the account credentials and access of the user account.  They also allow for services to be configured to run on a users behalf without having to give the user deeper levels of access to the system.

Additionally, if a user could access your computer well enough to establish a user like that, there is no reason they would need to create a user.  Loading a rootkit or a remote access trojan would allow for control of the user's computer without leaving a user account behind.  Some activity would possibly still end up in event logs for a simple remote access trojan, but a decent root kit could even subvert the system logging.

The attack scenario you describe is not a particularly viable attack scenario and isn't a security flaw, but rather a designed feature of Windows, implemented to improve security.


Can I decrypt files encrypted by Odin ransomware?

You won't be able to get your files back by any trivial means, sadly. You may be able to remove the ransomware itself, but you will not be able to retrieve your files without paying the ransom, for now, regardless of the language it was written in. The method used to encrypt these files makes them effectively useless unless you have the private keys, which they definitely won't give you, and you definitely won't guess. For anyone who is curious, Odin uses RSA-2048 bit and AES-128 bit ciphers.
Eventually, as you mentioned, there may be some sort of decryption tool for this strain of ransomware. Companies like Kaspersky and Sophos have already released tools for older varieties of ransomware. But until the time when a tool exists for this version of Odin specifically, you do not have many options.
Cold storage/offline backups are the best method for dealing with ransomware right now after the fact. Not to kick you while you're down, but avoiding malicious links, untrusted websites and downloads is the best way to avoid ransomware. Although I'm sure you've learned this lesson by now.
If you are on windows you could always try something like ShadowExplorer, you may have file backups you weren't aware of (hopefully).
The long and short of it is, your files are stuck in limbo until you pay for the decryption key, magically locate backups, or a method for decrypting this strain of ransomware becomes available, if it ever becomes available.


Firefox 68 --- any changes affecting CSRF capabilities?

Firefox 67 and 68 added multiple possible settings for privacy and Third-Party-Cookie-Blocking. As far as I understand, your demo seems to include usage of Third-Party-Cookies. You can find the information at the information page about content-blocking from Mozilla. The main reason for the change were protecting against being tracked by Third-Party-Advertisers and similar.

Further information:

When you open a page at evil.com, all content loaded from evil.com is considered First-Party-Content. Content loaded from other domains, is called Third-Party-Content. Depending on your privacy settings, Third-Party-Content might be loaded without cookies or not at all (for example if the domain got on a black-list). Since your (fake-)image from demo.com is considered Third-Party-Content, depending on your settings, the request might not contain the cookies of demo.com.


Why is the Java download only offered via HTTP, not HTTPS?

This is no excuse for Oracle not serving it's downloads over https, but there are SHA 256 and MD5 (yuck) hashes on the download page. The link is https.

This does rely on the user downloading the image to check the sha256, which unfortunately few people do.

When clicking on the 'checksum' link below you will hit a link like this:

https://oracle.com/webfolder/s/digest/8u131checksum.html


How to mitigate risk of leaking information of a user not found in database during login

Timing step 2 does leak information. In order for it not to, you'd need a database implementation where hits and misses take the same amount of time.

It is probably more important, though, that you run step 3 unconditionally. If a username is not in the database, then use a dummy value for the salt and execute your password hash using the same configuration you use for real accounts.

Step 2 would probably require more than one login request to "average out" noise from timing data. Conditionally executing step 3 would make timing attacks trivial.

I'm not familiar with real world database implementations. (Or their indexing options.) My guess is that no major DB supports a constant time indexing mode. There might be indexing options that are closer than others to being constant time.

Hash-table-based indexing schemes that don't use bloom filters or caches might be one of the least bad options. Perhaps there is some type of index that will only ever do one disk seek for any key lookup.

Hit and miss times after the disk-seek will still vary, but then hopefully it won't vary by much. Precise timing then might be made more difficult by other unpredictable sources of timing variability. (Seek times, server load, or network conditions, for example.)


Why is hashing (digest) employed in digital signatures?

Why not just encrypt the message with private key?

As far as I know, it's just for efficiency. Encrypting with asymmetric algorithms is notoriously a time (and resource) consuming operation, particularly when the plaintext size is rather large (MB, even GB).

To avoid that, you just encrypt the hash, which has a much shorter length, and still guarantees that the signed file can't have been altered.

  I assume that then attacker could just change something, we would be able to decode, but we would get different message than the sent one. We also wouldn't be able to recognize that the message was changed.

In general, yes, only cryptographic hashes (and related techniques such as message authentication codes) allow you to recognize that the message hasn't been changed. However, with most modern algorithms an attacker cannot easily modify the ciphertext E(m) to a value corresponding to another arbitrary message m'.

  Why not just encrypt the message and append the encrypted one to the original message?

Do you mean m|E(m), i.e. plaintext concatenated with its ciphertext encrypted with the private key? If so, it's again mostly due to effiency reasons. As I have already said, encrypting a document asymmetrically is a computationally expensive operation. In addition, as you have correctly said, the size would be almost doubled.


How to verify that a clientside-generated object is genuine?

You can't prove it, no. It's on the client machine, so any code or data you hand them is theirs to change. At best you can make it difficult, with obfuscation and DRM techniques, but that's likely to introduce other problems.

The only solution to this problem is to perform operations on the server.


How many possible randomly generated salts could be generated using PHP's password_hash() function?

1) The salt for password_hash() is a 128 bit salt which is the first 22 base64 characters after the cost factor. In your example, the salt would be x27FUiXA/hFKjD7NDxyD6e. Because it is 128 bit, you can calculate the number of potential salts as 2^128 which is 3.4028237e+38. So, in short, a lot.

2) Well this didn't seem like a question so i'll try to answer the "which characters indicate the hash" part. The hash are the remaining 31 characters after the salt. In your case 63ac4gmCkTqXRpmy1Rk.MxXAqRd8yO6.

(also, your understanding is correct. 2y is the algorithm, and 10 is the cost.)

It is important to note that password_hash() can change its implementation to use a different algorithm if you update PHP to a newer version that changes it.

  PASSWORD_DEFAULT - Use the bcrypt algorithm (default as of PHP 5.5.0). Note that this constant is designed to change over time as new and stronger algorithms are added to PHP.

If you use PASSWORD_BCRYPT it will always use bcrypt.


I can upload any file to an ASP webapp/IIS server but I do not know where (which folder), is this exploitable?

A few things to try:

Brute force a bit harder for directory names, perhaps using Dirbuster
Try to force an error message; this may reveal the path
Is there any way for the user to view an uploaded file? Look at that functionality in detail

If the files are stored outside the web root then this may be non-exploitable. However...

One other thing to look for is local file inclusion. This is where you upload a malicious script, then trick a legitimate script into including your malicious script. This is quite widely seen with PHP sites, but it also works with ASP.


Data too large for key size while trying to sign then encrypt

Based on this comment you can encrypt at most 214 bytes using 2048 bits RSA key.

When i run the same operation you did, i get the following:

$ ls -lah
total 44K
drwxr-xr-x  3 my_user my_user 4.0K Sep 27 10:50 .
drwxrwxrwt 20 root       root       4.0K Sep 27 10:49 ..
-rw-r--r--  1 my_user my_user  658 Sep 27 10:49 pouet.sh
-rw-------  1 my_user my_user 1.8K Sep 27 10:49 private.pem
-rw-r--r--  1 my_user my_user  451 Sep 27 10:50 public.pem
-rw-r--r--  1 my_user my_user   33 Sep 27 10:50 symmetric_keyfile.key
-rw-r--r--  1 my_user my_user    0 Sep 27 10:50 symmetric_keyfile.key.enc
-rw-r--r--  1 my_user my_user  256 Sep 27 10:50 symmetric_keyfile.key.sign
drwxr-xr-x  9 my_user my_user 4.0K Sep 27 10:49 update
-rw-r--r--  1 my_user my_user 3.5K Sep 27 10:50 update.zip
-rw-r--r--  1 my_user my_user 4.2K Sep 27 10:50 update.zip.enc

Since you're trying to encrypt symmetric_keyfile.key.sign which is 256 bytes, the failure is quite normal.
Given my poor skills regarding crypto, i would suggest that you do not sign your key before encrypting.
In my opinion, this step is useless...


What is safebrowsing.google.com ?Does it impact the security testing?

Firefox takes hashes of various page parameters (mainly URL segments) and passes them back as part of Google's SafeBrowsing scheme. It cannot readily identify parameters or other information that you pass to the target - it's just used to check against a list of known attack domains.

As per these instructions, you can turn SafeBrowse off:

  Firefox button > Options > Options (or Tools > Options) > Security, un-check both "Block reported attack sites" and "Block reported web forgeries"


Security Measures For Banking Information

You should probably get someone with more security background to actually look over your site to make sure things are properly implemented and to design your security for you.  Building a system that can safely protect banking information requires a lot of different knowledge and, no offense intended, your question itself demonstrates that you likely have very little experience in this regards.

Encryption does not use a salt, it uses an IV.  Salts are used with hashes. Initialization Vectors ensure that different encryptions of the same information result in different cyphertexts (to prevent the same encrypted value from being recognizable as the same). Beyond encryption for the data, you will need a secure account setup, you will need to prevent against sql injection and cross site scripting, you will need to verify a bunch of things about your server environment and the network it is on, you will need to setup intrusion monitoring.

There is a whole slew of things that go well beyond what we can tell you about in sufficient detail on this site in one answer and there are a lot of pitfalls that can occur based on how you write your code specifically.  You really need someone to work with you directly if you are building your own application for this from the ground up.


How is my microsoft account compromised?

Changing a password does not typically revoke existing access. I'm not familiar enough with a Microsoft account, so I'll provide a general suggestion that many modern websites use.

Twitter has a section in your profile settings that list all connected applications to your account. This can be other twitter clients, or other services that use your twitter data some way. Once connected, this access usually persists through password changes. See if MS has a similar settings page and if so, revoke every application you see and then if something breaks on your end, add that access back.

So how was your account compromised after the password change? It likely wasn't. The user has an authorization token that hasn't been revoked yet. That would be my guess.


Why do I get spam in my newly created email account before even using it?

It looks like you already have your answer. Your email address is easily guessable since it follows a very common naming convention. This is a problem today, even for large corporations. The takeaway here, if you're interested, is to avoid using email addresses in applications you use or design, as a log in username. Also, if you are using your email address across multiple applications on the Internet, ensure you are using unique passwords and understand the risk of someone attempting to access those apps (e.g. banks) with credentials they stole somewhere else.


Why is asymmetric encryption less efficient than symmetric encryption?

This depends on the algorithm. Especially with asymmetric cryptography, the speeds vary wildly. You may want to check out eBACS for more detailed and machine-independent benchmarking of various crypto primitives. As always, you need to perform your own benchmark on your own system to know exactly what to expect on a production system under the chosen conditions.
You should never use asymmetric ciphers to encrypt anything directly. If you encrypt anything other than a key, you can run into the risk of making cryptanalysis possible. RSA for example does not like encrypting non-random data. This is fine when you are encrypting a key (which is random, after all), but not if you are encrypting ASCII. Quoted from another answer (emphasis mine):

RSA has some operational constraints. With the most used variant (the one known as PKCS#1 v1.5), if the size of the RSA key is "1024 bits" (meaning that the central mathematical component of the key pair is a 1024-bit integer), then RSA can encrypt a message up to 117 bytes in length, and yields an encrypted message of length 128 bytes. That limited size, and the size increase when encrypting, are unavoidable consequences of the mathematical structure of the RSA encryption process. Due to these constraints, we do not usually encrypt data directly with RSA; instead, we select a small sequence of random bytes, which we call session key. We encrypt the session key with RSA; and then we use the session key with a symmetric encryption algorithm to process the whole message. This is called hybrid encryption.

Encrypting a small amount of data with a symmetric cipher will not let you benefit as much from its higher speed. Most symmetric ciphers have a certain one-time setup cost called the key schedule, where the key is processed and split up into separate subkeys for each component of the cipher, or spread out among the cipher's internal state. These subkeys are usually cached so they can be used directly each time the cipher is invoked. Each time a new key is used, the key schedule is run and must complete before anything can be encrypted. Some ciphers have very expensive key schedules, such as Blowfish, whose key schedule is equivalent to 521 Blowfish encryptions requiring 4 KiB of RAM and is the basis of the slow bcrypt function. Others have very simple key schedules, like TEA which simply splits the key up and mixes it with constants. When you are encrypting a large amount of data with a single key, you are able to benefit more from the speed of a fast cipher than if you are encrypting small chunks data independently.

A quick benchmark on a low-end system (Pentium III, 1 GHz) at medium load is below. Note that these benchmarks only show how fast these algorithms are on this specific machine. It may be accurate to within an order of magnitude, but a faster machine with different capabilities may not only be faster, the relative speed of the individual algorithms might be different! But to get an idea...
RSA, with different sizes:

OpenSSL> speed rsa
...
                  sign    verify    sign/s verify/s*
rsa  512 bits 0.001305s 0.000113s    766.2   8881.1
rsa 1024 bits 0.007685s 0.000372s    130.1   2687.5
rsa 2048 bits 0.050615s 0.001355s     19.8    738.1
rsa 4096 bits 0.353636s 0.005201s      2.8    192.3

AES, with different key sizes and input lengths:

OpenSSL> speed aes
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes     256 bytes    1024 bytes   8192 bytes
aes-128 cbc      21174.71k    23656.67k    24212.96k    39798.65k    40800.k
aes-192 cbc      18706.23k    20713.58k    21222.25k    34669.23k    35059.k
aes-256 cbc      16153.38k    17569.97k    18004.69k    30170.76k    30020.k

SHA-256, with various input lengths:

OpenSSL> speed sha256
...
The 'numbers' are in 1000s of bytes per second processed.
type              16 bytes    64 bytes     256 bytes    1024 bytes   8192 bytes
sha256            6537.11k    14781.14k    26256.93k    32630.49k    34562.k
* In textbook RSA, signature verification is identical to encryption, and signing is identical to decryption. Verification involves determining if se ≡ m (mod n), whereas encryption is running c ≡ me (mod n). In the real world, there are important differences involving special padding operations necessary to prevent RSA from being trivially broken.

I suppose you're wondering why there is this difference in performance. The reason has to do with how these cryptographic primitives work. A basic explanation of asymmetric ciphers, symmetric ciphers, and hash functions, along with what influences their performance, is below.
Asymmetric ciphers involve so-called hardness problems. These are open problems in mathematics which exploit the fact that an operation is easy to perform in one direction, but difficult to operate in reverse without a secret value. RSA uses the fact that it is trivial to multiply two huge prime numbers together, but prohibitively difficult to factor the resulting composite number back into the original primes without at least one of the original prime numbers. For textbook RSA, encrypting message m requires you compute c ≡ me (mod n). To decrypt c, compute m ≡ cd (mod n). Here, n is the product of the two secret primes, p and q, and d is the modular inverse of e (a public exponent which is often chosen to be a Fermat prime), found by calculating d ≡ e-1 mod (p - 1)(q - 1).
Asymmetric ciphers can vary wildly in speed because they all involve different mathematical concepts. Even distinct ciphers that use the same concepts (such as RSA and the Rabin cryptosystem) can vary in speed. These algorithms are often so slow because they require operating on very large numbers all at once, which is difficult for our modern CPUs that can only efficiently process 64-bit numbers (or a few times more, up to 512 bits for the most recent CPUs, when special optimizations are used). Modular arithmetic in particular is trivial when involving 64-bit integers on a 64-bit processor, but is very inefficient when massive 2048-bit numbers are involved.
Symmetric ciphers come in two types: stream ciphers and block ciphers*. Stream ciphers use the key to generate an endless deterministic stream of pseudorandom bytes (the keystream). This stream is combined with plaintext to form ciphertext. Decryption involves the same operation, combining the keystream with the ciphertext to obtain the plaintext. A block cipher on the other hand takes a key and uses it to permute an input of a fixed block, outputting a ciphertext block of the same size. A block cipher can be run in reverse with the same key to decrypt the ciphertext. Block ciphers must be run in a mode of operation to securely encrypt more than a single block of data with a key. Some modes allow for parallel implementations. Others must be serialized, whereas others still may be parallelized for encryption but not decryption, or vice versa.
Symmetric ciphers are very fast because they involve only the concepts of confusion (the output gives no hints about the input or key) and diffusion (a small change in either the input or the key causes a drastic change in the output). Unlike asymmetric ciphers which typically act on massive numbers, symmetric ciphers involve a large number of very simple key-dependent operations being repeated many times. Each operation is small enough to be computed efficiently by a CPU. In particular, ciphers using the ARX scheme (such as Salsa20) require only additions, rotations, and XOR operations on very small word-sized chunks of data, which can be implemented extremely efficiently on processors. There are no arithmetic operations on unwieldy numbers.
Hash functions are very similar to symmetric ciphers and they involve the same concepts of confusion and diffusion. In fact, hash functions are sometimes used to create ciphers, and vice versa†. This can be seen with Salsa20, a stream cipher that uses a hash at its core, and Whirlpool, a hash function which uses a modified version of AES. A hash function takes an input of effectively unlimited size and outputs a digest of fixed size. Like a cipher, confusion prevents an attacker from learning anything about the input from the output, and diffusion amplifies small changes to the input.
Hashes are often slower than symmetric ciphers because they have more strict requirements. In particular, hashes must not only prevent an attacker from reversing the operation (a preimage attack) and modifying an input without the hash changing (a second preimage attack), it also must make it hard to generate a pair of inputs that create the same hash (a collision attack). Being collision-resistant is hard and tends to require a rather slow and complex hash. To put it into perspective, an attacker can collide the horribly broken MD4 hash with less effort than it takes to invoke the function twice. Even still, the best preimage attack on it is purely theoretical.
* Stream cipher encryption is C = P ⊕ EK and decryption is P = C ⊕ EK where P is plaintext, C is ciphertext, and EK is the keystream generated with key K. For a block cipher, encryption is C = EK(P) and decryption is P = DK(C) for a single block of P and C. A mode of operation is required to process more than a single P or C given a single K.
† When using a hash function to construct a cipher or vice versa, the security properties demanded from the hash are different. For example, Salsa20 is a secure stream cipher despite the fact that it is built off of a hash function which lacks collision resistance. Likewise, a hash built out of a cipher requires the cipher be secure against related-key attacks, which is not necessarily required for a secure cipher on its own.


I believe it is legitimate.  If you visit paypal.com, switch to the "Germany - Deutsch" site and check out the links on the resulting site, you can see that, for example, the "Sicherheit" (Google translate as "Security") link points to https://www.paypal-deutschland.de/sicherheit/.

Of course, one could argue that this means very little.

If in doubt, visit paypal.com and use the designated German site which appears to remain on the paypal.com main domain.


Viewing local users on a workstation when I'm SYSTEM on Forest PDC

Well if you've ever used the "Local Users & Groups" snap-in, you'll know this is possible.  Just remember that the accounts aren't actually going to be in AD at all, so you'll need to have the remote server do the lookup for you.  In a C program, you can use NetUserGetInfo to get details on a specific account or NetUserEnum to get a list of all users.

However, I think your best bet might be to use PowerShell.  Here's an example:

([ADSI] 'WinNT://TABLET').Children |
    Where {$_.schemaClassName -match "user"} |
    Select Name, objectSid |
    ForEach-Object {
        New-Object -TypeName PSObject -Property @{
            Name = $_.name[0]
            SID = (New-Object Security.Principal.SecurityIdentifier ($_.objectSid[0]), 0).Value
        }
    } | Format-Table


In what situations should a node ping/not ping?

ICMP can be dropped for a variety of reasons to protect the service. And there are obviously clear reasons why ICMP is useful.
If you take the stance that you only allow services that you have a stated reason to enable, then the default would be to drop ICMP, and only allow it for specific reasons. Firewalls always start with a default DENY, and then you build ALLOW rules on top of that.
In your example, it appears that there are admin-type machines that need to ping everything. This is not unusual for admin machines.
Client-type machines likely have no reason to ping the service, so that would fall under the default DENY because you would not craft an ALLOW rule for the clients without a reason.


You've just acquired a newly created CentOS server, what should you do to secure it?

The easiest way is to harden it by using the DISA/STIG (Security Technical Implementation Guides) compliance standards which are published by the department of defence.

They are quite comprehensive and exhaustive when it comes to server hardening. You can find them here: http://iase.disa.mil/stigs/.

Aside from server hardening you also need to make sure your app is written in accordance to the OWASP web application best practices.

Aside from a normal firewall you should also deploy a Web Application Firewall (WAF) such as mod_security and a host based intrusion detection system (OSSEC).

Preferably you do not expose management interfaces such as SSH on the public IP and all logging should be done towards a separate loging server (of course if your server infrastructure only covers this single server that might not be an issue).