Out of the blue, there are only strangers. Two people who don't know each other beforehand cannot, by themselves, establish a secure communication free of impersonation by third parties, because that's not defined. I cannot make sure that I talk with "Bob" if I have no reference framework for who or what "Bob" may be.

Suppose that Alice wants to talk securely with Bob. She has an a priori notion of "Bob". She does not want to talk to just any Bob, but with a specific Bob. Let's take an example: Alice wants to do business with Acme Ltd., a "well-known" corporation. From the point of view of Alice, there is a large body of evidence that there is such a thing as a corporation known as Acme Ltd, which sells a specific kind of goods and/or services that Alice is interested in. Alice thus wants to talk to an authorized salesman from Acme Ltd. Authorized by whom ? By Acme Ltd, of course. If Acme Ltd. says that Bob is the man to talk with, then Alice wants the public key of Bob, that Bob, the one and unique Bob from Acme Ltd. That Bob is defined as "the Acme Ltd salesman". It is Acme Ltd who asserts Bob's identity. In that case, sending to Alice the public key of Bob becomes naturally Acme's job.

Thus, Alice will receive Bob's public key from Acme Ltd. How does Alice know that what she receives really comes from Acme Ltd, the corporation ? There again, this depends on Alice knowing Acme's public key, bound to Acme's identity as asserted by... whoever is in position to give names to corporations. This usually is a chamber of commerce: the corporation is registered with that chamber, and the chamber is the entity which says "this corporation bears that name". Thus, the chamber of commerce should send to Alice the public key of Acme Ltd. Of course, this sending will use some sort of authentication (e.g. a signature) so that Alice knows that it really talks to the actual chamber of commerce.

So Alice now needs to know the chamber of commerce's public key. Since chamber of commerces tend to be public entities, this gets us to the state or country which contains that chamber of commerce. And so on...

Here I am retracing the classic hierarchical public-key infrastructure model: you get public keys from the entities who are in charge of defining names. There could be some sort of delegation. For instance, if Alice visits Acme's Web site, and the Web site uses HTTPS (i.e. SSL), then that Web server will present a certificate. That certificate is signed by a Certification Authority, which is not operated by the chamber of commerce; instead, it is a private entity who accepted to sign the certificate because Acme's sysadmin presented to the CA some documents, emanating from the chamber of commerce, which demonstrate that the certificate request really comes from Acme Ltd.

With some kind of domains (notoriously the .com, .org... domains), the coupling is looser: a certificate will be issued to a requester as long as he demonstrates that he technically controls the relevant domain. It is assumed that if there was some foul play (e.g. DNS poisoning) then the true Acme Ltd will complain at some point, and certificate revocation will be employed to fix the issue. This is still hierarchical because the chamber of commerce, state... will be invoked during litigation to demonstrate that there is a corporation named Acme Ltd, and the name "Acme" really belongs to Acme Ltd.

The naming, in the legal sense of the term, is intrinsically hierarchical. It is a monopoly of modern states; indeed, it was a cause of conflict in many countries during the last two or three centuries (in older times, names were handled by the "community", usually the local church, not by any central state). However, a decentralized, community-driven naming can still be used.

For instance, suppose that you want to send a private email to Linus Torvalds, creator of the Linux operating system. What notion of identity will you use ? Do you want to talk to "Linus Torvalds", as defined by the Finnish authorities (he is from Finland) ? Or do you want to talk to the famous Linus Torvalds, creator of Linux ? This is a case where the notion of identity is driven by fame, i.e. Linus Torvalds is whoever is designated as Linus Torvalds by a lot of people.

This leads to the Web of Trust. This uses the same concept of certificates as the PKI (a certificate being an object containing a name and a public key, and signed by someone). However, in the WoT, everybody acts as a CA. We don't use "naturally designed" CA. Every single person can simply assert bindings between identities and public keys.

How can a WoT provide any kind of security ? Liars exist. Alice may build a chain from her to Bob:

Alice knows Charlie's public key (Charlie is a friend of Alice).
Charlie knows Darren's public key, and has issued a certificate for that: the certificate contains Darren's name and Darren's public key, and is signed by Charlie.
Darren knows Ernest's public key, and has issued a certificate for him.
Ernest knows Bob's public key, and has issued a certificate for him.

Alice thus knows Darren's public key provided that she trusts Charlie for not being a liar (or being very gullible). Charlie is Alice's friend, so Alice may make some good assumptions on Charlie's reliability. Now Alice knows Ernest's public key, provided that Darren is not a liar. So Alice must trust not only that Charlie is not a liar, but also that Charlie is good at judging people and would not have issued a certificate to a liar. Then we get to Bob: for that, Alice must trust that Charlie is not a liar, would not have issued a certificate to a liar, and would not have issued a certificate to someone who would accept to issue a certificate to a liar. This begins to entail a lot of nested assumptions...

The important point is that the WoT relies on community-driven identities: an identity is defined by a lot of people agreeing on it. The WoT is secure not because you build and verify one chain, but many chains which go through distinct people's keys, and they all agree to assert that Bob is Bob. This is the oft-forgotten necessary condition for security -- and, in practice, it does not work well (or at all). You can already consider yourself lucky if you can build one chain from you to your intended recipient.

So there are always "authorities". With a classic hierarchical PKI (as is used, for instance, in X.509 certificates for SSL servers), the list of such authorities can be known and controlled by each user (this is the "trusted root" certificate store in his OS or browser). With a Web of Trust, the authorities are "the people" and security relies on "the people" to be, on average, honest (there can be liars, but most people are not).

Unfortunately, the Web of Trust will yield enough security only at great expense: the graph of certifications must be very redundant, and whenever you are trying to validate the purported public key of someone, you must gather many distinct chains, and verify them all. If you do not do that, then Evil People (insert your favourite three-letter agency here) could easily bootstrap a fake identity by bribing or fooling two or three persons.

So you cannot avoid "authorities", but you can choose your poison. There is, though, a powerful mitigation called memory: if, at some point, you obtained the public key of someone, then you can remember it and use that key thereafter. This is the model of SSH (the .ssh/known_hosts file) and it works well with usual OpenPGP implementations (that's called "your keyring"). It is not perfect, though, because memory-based PKI must still be bootstrapped (to remember a public key, you first have to learn it) and does not work well with key renewal or revocation.


No dice
I don't think you'll find a way to pin the mail server cert across all these clients. Not unless you cripple the devices' cert stores down to only your own CA's cert. And that would work. But it would also mean that regular HTTPS would stop working.

VPN instead?
Could you put your mail server behind a VPN instead? This should be easier to nail down to just a specify cert on the clients.


Generating random passwords by clicking randomly on the keyboard?

Such passwords will be as random as your fingers can be. Humans banging on keyboards tend not to be very random; for instance, they will often alternate between left-side keys and right-side keys. As a rule of thumb, such a passwords would probably be reasonably secure if you make it long enough, about twice as long as a random password generated with a good randomness generator.

The main problem with a password crafted with such a "manual process" is that it is very hard to quantify its randomness. Especially if you generate several such passwords: I would expect successive "keyboard-random" passwords from the same human user to exhibit similarities. Thus, you have to overdo it in order to regain some guarantees, which means longer passwords (and nobody likes to type long passwords).

I recommend using a strong random generator. Dice will do; coins too (but a d20 will give you more randomness per throw than a coin). If you happen to have a computer available at that time, well, it can be used too.


That's a tough one. Real domain "ownership" happens at the registrar level. Subdomains can be doled out by the domain registrant, but that level of of ownership is difficult to verify, and the terms and duration of your control over a given subdomain are not necessarily clear to the CA. As such, CAs that do simple domain control validation would categorically deny any such requests; it wouldn't fit the security rules they've set up.

Instead, such request would have to go through the domain owner, like FreeDNS. They're the only party that could realistically determine whether or not such a cert should be granted and for how long, and therefore they're the ones who the CA would want to talk to.

A better solution is to register your own TLD. Dynamic DNS can still be done with your own domain name, plus it simplifies your interaction with CAs and other similar organizations.

Alternately, you can always use a self-signed certificate. Self-signed certs are just as secure as CA-signed certs as long as you can verify that the site is serving your certificate. In fact, if you're doing custom certificate validation in your browser, it's actually more secure than a CA-signed cert because you're not subject to attacks involving malicious but properly-signed certificates.


What considerations would need to be taken into account when purchasing a house with multiple smart home appliances?

That is an interesting question.

You have already given the theorical answer: it is not only your sister-in-law's system but it is the one of the previous owner too. So you can only trust it if you trust him. At one level, security is always a matter of threat, risk, and trust.

I would agree with your sister-in-law in one point: if she trust the previous owner enough to buy him a house, why not trust him to honestly give her full control on the smart devices? On a legal point of view, he must, and could be in trouble is you could prove he has not.

There is a second point though: how secure is the system on its own? I mean, what are the currently implemented security measures to avoid that anybody passing in front of the house can take control of it? I the previous owner was a tech-lover, it may be correctly secured, but it is very important IMHO that you syster-in-law (eventually with your help) understand enough of it to know what she can, must and cannot do to keep it secure. Typically, if you can control everything with a smartphone, how is the smartphone or smartphone owner identified?

It is currently said that the major threat for a computer lies between the keyboard and the chair, and it is often true in security too: most risks can be mitigated except the user if not educated enough to security.

The following is no more than my advice, and I admit I'm not directly concerned here, so please read it only that way. I think that as she trust the previous owner enough to buy him a house, she can trust him to give her full control and not try to spy her. But she must:

get enough understanding on the full thing to be able to keep it secure
get enough understanding to be able to control if someone or something has come into the system - this is just a special case of the first requirement, and perhaps the most important, but you can help her on that part


What are the possible security issues (breach/losing access) with sharing passwords manually?

Sharing a password is always a problem because you never know where it is going to end up. For example, if you send it by email, it might end up in the backups of the hosting provider, in the email client of whoever you sent it to, etc. Not to mention that apparently email can still be sent in the clear (not encrypted) from one server to another, or at least so I learned. As for Skype for example, the password might remain in the chat history, either on the user's device or on Microsoft's servers.

Apparently (or so I learned) an acceptable way to share a password is to use separate channels to send the information. For example, you might encrypt it, and send it encrypted via email, and then tell the password for decryption in a phone call. Or send a piece of the password via SMS, and the rest in a phone call. This way it's going to be harder for an attacker to intercept the password or recover it.

As you see all this can get pretty complicated (and a pain in the neck). LastPass and other online password managers then can make your life easier for this task, by allowing users to share some passwords with other accounts.


Multi-Single-Factor vs. Multi-Factor Authentication

This definition you share for multi-factor authentication does not meet the commonly accepted industry definition.  Multi-factor just means that two or more factors, typically from different categories of authenticators, are used to authenticate.  It isn't specific regarding whether these factors unlock access to a local 'secret' that is used for further authentication or sent directly to the authentication server.

Either scenario still involves multi-factor authentication.  What these factors unlock as far as secrets, session tokens, or the like shouldn't really affect their name.

I can't say I've ever heard the term "multiple single-factor-authenticator" before.  I'd interpret this to mean you have a system that uses two factors from the same category, e.g. a password and a PIN.

Multi-factor authentication is generally going to be more secure than single factor because it should be more difficult for an attacker to compromise multiple factors.  They might be able to guess your password, but it is more difficult to both guess it and obtain a valid OTP tokencode.


A good thing to do when proposing a security concept, is to create a list of scenarios, that it needs to protect against. Without that framework, it is hard to comment.

Let's compare it with session handling:

The user logs in (or accesses the site)
A random token called sessionid is generated
The sessionid (and other information linked to it) is stored on the server (in a database, filesystem or memory)
When the user accesses a page, a function is called which checks the session id and reads associated information. If the sessionid is valid, the user stays logged in. If not, the user is logged out.

So the main difference is step 5, in which you generate a new token for the next request.

So if one request is missed, the user will be logged out. This might help a user to detect that he was a victim of a CSRF attack. But being logged out will most likely not raise much suspicious to normal users.

You force a strict order of requests. If two requests are processed in parallel (e. g. opening two browser tabs within a short time frame), both will send the same cookie. As a result, one tab will fail and the user will be logged out.


How can an Android device be unlocked, and how long would that take?

I can see two attack vectors.

The device is booted and at the lock screen.
Either a lock screen bypass or crashing the lock screen will work here. Exact methods will change depending upon which Android version you run. But the key point is that the Android lock screen is a screen overlay on Android 4, so crashing the lock screen will put you straight onto the home screen.

Android 5.x has CVE-2015-3860 vulnerability.

This presumes the device does not have full-disk encryption enabled

If the device is not encrypted, boot into recovery mode and flash a custom ROM. You can change, disable or remove the stock lock screen. As you will have root access over the file system. Furthermore, you can access the file system directly without needing to worry about the password.

For encryption, Android 5.0 and upward full-disk encryption (/data is encrypted) is deployed and Android 7.0 and upward file-based encryption. Full-disk and file-based encryption. Full-disk encryption can be cracked by exploiting CVE-2016-2431. For those using unencrypted Android, the hash can be accessed via /data and brute forced.


Does Azure Key-Vault encrypt the values before storing?

You don't make clear exactly how you intend using Key-Vault.

As a general guide to encryption you should always ask the question, "Who has the keys?"

Many storage services offer to perform encryption for you, but if the encryption is not with your keys, it's not your protection.


How do organizations check *what* has been hacked?

In a word: Forensics.

Computer forensics is the art of examining a system and determining what happened upon it previously.  The examination of file and memory artifacts, especially file timelines, can paint a very clear picture of what the attacker did, when they did it, and what they took.

Just as an example - given a memory dump of a Windows system, it is possible to extract not only the command lines typed by an attacker, but also the output that they saw as a result of running those commands.  Pretty useful in determining impact, eh?

Depending on the freshness of the compromise, it's possible to tell quite a lot about what happened.

@AleksandrDubinsky suggested that it would be useful to outline the various Computer Forensic fields and techniques, which I'm happy to do for you.  They include, but are not limited to, the following (I'm going to use my rough terms; they aren't official or comprehensive):

Log/Monitor Forensics: The use of 'external' data such as centralized logs, firewall logs, packet captures, and IDS hits straddles the line between "Detection" and "Forensics".  Some of the data, like logs (even centralized) cannot be trusted to be complete or even truthful, as attackers can filter it or inject it once they have control of the system.  Off-the-system packet logging tools like the firewall, IDS, or packet recorders (such as (formerly)NetWitness) are unlikely to be tampered with, but contain only a limited amount information; usually just a record of IP conversations and sometimes signatures (such as HTTP URLs) associated with malicious activity.

Unless an unencrypted network connection was used in the compromise, these tools are rarely able to detail the activity during a compromise, and so (going back to the original question) don't "check what has been hacked."  On the other hand, if an unencrypted connection (ftp) was used to exfiltrate data out, and full packets were recorded, then it's possible to know exactly what data the attacker ran away with.

Live Forensics:  More properly part of Incident Response, so-called "Live" forensics involves logging into the system and looking around.  Investigators may enumerate processes, look in applications (e.g. browser history), and explore the file system looking for indications of what happened.  Again, this is usually designed to verify a compromise happened, and not to determine the extent of a compromise, since a compromised system is capable of hiding files, processes, network connections, really anything it wants to.  The plus side is that it allows access to memory-resident things (processes, open network connections) that aren't available once you shut the system down to image the disk (but, again, the system may be lying, if it's compromised!)

Filesystem Forensics: Once a copy of the disk has been made, it can be mounted on a clean system and explored, removing any chance of the the compromised operating system "lying" about what files are in place.  Tools exist to build timelines using the variety of timestamps and other metadata available,
incorporating file data, registry data (on Windows), even application data (e.g. browser history).  It's not just file write times that are used; file read times can indicate which files have been viewed and also which programs have been executed (and when).  Suspicious files can be run through clean antivirus checkers, signatures made and submitted, executables loaded into debuggers and explored, "strings" used to search for keywords.  On Unix, "history" files - if not turned off by the attacker - may detail the commands the attacker entered.  On Windows, the Shadow Copy Service may provide snapshots of past activity that has since been cleaned up.

This is the step most commonly used to determine the scope and extent of a compromise, and to determine what data may or may not have been accessed and/or exfiltrated.  This is the best answer to how we "check what has been hacked."

Disk Forensics: Deleted files disappear from the filesystem, but not from the disk.  Also, clever attackers may hide their files in the "slack space" of existing files.  These things can only be found by examining the raw disk bytes, and tools like The Sleuth Kit exist to rip that raw data apart and determine what it means about the past.  If there was a .bash_history file, and the attacker deleted it as his last step before logging out, then that file may still exist as disk blocks, and be recoverable.  Likewise, attack tools that were downloaded and temporary data files that were exfiltrated can help determine the extent of the compromise.

Memory Forensics: If the investigator can get there soon enough, and get a snapshot of the memory of the system involved, then they can thoroughly plumb the depths of the compromise.  An attacker must compromise the kernel to hide from programs, but there's no way to hide what's been done if a true image of kernel memory can be made.  And just as the disk blocks contain data that has since been removed from the filesystem, the memory dump contains data that was in memory in the past (such as command line history and output!) that has not yet been overwritten... and most data is not overwritten quickly.

Want more? There are training programs and certifications to learn Forensics; probably the most common publicly available training is from SANS.  I hold their GCFA ("Forensic Analyst") certification.  You can also review the Challenges from the Honeynet Project, in which parties compete to unravel the cases given disk images, memory dumps, and malware samples from actual compromises - they submit their reports of what they found, so you can see the sorts of tools used and findings made in this field.

Anti-Forensics is a hot topic in the comments - basically, "can't the attacker just hide their traces?"  There are ways to chip away at it - see this list of techniques - but it's far from perfect and not what I'd call reliable.  When you consider that "the 'God' of cyberespionage" went so far as to occupy the firmware of the hard drive to maintain access to a system without leaving a trace on the system itself - and still got detected - it seems clear that, in the end, it's easier to detect evidence than it is to erase it.


Why is "something you know" the weakest factor of authentication?

In the typical case, something you are and something you have can only be true for one person at a time. If you lose your token, you know you have lost it.

Something you know can be copied by someone without your knowledge. If someone has your password, you may not be able to tell that they are actively exploiting that knowledge.

That is one reason to change your password regularly. It shortens the window where a password breach could be exploited.


does karabiner elements on Mac OSX contain or potentially contain malware?

first let me just say; I am not sure anyone here would be willing to read through it but my advice would be:

1: read through the bug reports

2: google information on it and read as many reviews as you can. it has a lot of eyes on it, but yea easy to be sceptical.

3: you could always sandbox it and monitor it, but still not a sure way.

Long story short, unless a you read the code your self or find someone reviewing the code via google you will just have to go with your gut. it has a fair amount of popularity.

not a lot of people read the source code of something open source, because its open source and they automatically trust it. So it is good you are sceptical, open source does not mean safe as you seem to be aware.


What does SSI signal does mean in captured packets in wireshark?

A similar point has been answered on Wireshark's own SO/SE in How to interpret signal strength.  Yet we can add some more details here.  And add some up to date links since the ones on that answer died.

The SSI Signal is radiotap's antena signal (and the SSI noise is the antenna noise) and we see in there:

  RF signal power at the antenna. This field contains a single signed 8-bit value, which indicates the RF signal power at the antenna, in decibels difference from 1mW.

*(emphasis mine)

Borrowing from the answer on wireshark's SO we have:

10((dBm-30)/10) Watts

So, yeah, that pretty much is signal power.  But note that that is:

What your card is telling you, radiotap is an encapsulation, not something that actually went through the air.  Therefore:

  the sniffing network adapter received the packet or it represents the power at which a nearby AP (access point) received this packet?

It is the sniffing adapter/card/antenna.
Not the strength of the signal for the packet it is the strength of the signal at the time that the packet was received.  Now, as we saw in the radiotap quote above, it is the power at the antenna.  But note that there is also noise there (SSI noise).  I'm not particularly confident that:

SSI Signal - SSI Noise = Actual power that the *packet* was received

This is because you have Signal to Noise Ratio, and some of the noise could have been interpreted as part of the signal.  SNR is beyond me though.

In summary, radiotap is the encapsulation of the state of your network card and antenna at the time that the packet was received.  Whether that can be used as an estimate of AP signal strength is debatable.  Since the signal strength is the signal of the network that the card is retrieving packets from and the rest is (more-or-less) noise then you can use that as an estimate.

In laboratory conditions I'd argue that the signal strength presented in the radiotap is a good enough estimate of signal AP strength discounted the distance from the AP.  Yet, in  the real world, e.g. in an urban area with a lot of APs and interference, the radiotap signal strength is neigh useless to tell you anything about an AP.

Extra

Also note that the radiotap encapsulation is part of IEEE 802.11 and is defacto standard for captured wireless packets.  Calling it a header is an oversimplification.  There is a header that defines several fields that may be present or not and then there is a list of fields that a certain card may or may not provide (but should tell you which ones are provided through the header).  This can be analogous to TCP and TCP options.

For example, in the Linux kernel code you can find the definition of the header in include/net/ieee80211_radiotap.h.  And then the structure that is built after the header in net/wireless/radiotap.c.

Some useful reading:

radiotap description
wireshark usage for RF


It is usually not the case that the DNS request is simply blocked but instead the firewall (or even ISP) will try to send a valid DNS response back so that the client quickly gets back that the domain does not exist or that it resolves to server which shows a warning message about blocked access.

To do this the firewall need to somehow intercept the original DNS request. Since most clients simply use the DNS server provided by the firewall anyway directly or indirectly (i.e. firewall is the central DNS server for resolving IP external domains) it is often sufficient to just configure the server to return a response configured by the ISP instead of the real response. For clients which explicitly use different DNS servers any access to some site port 53 (i.e. DNS) could be intercepted and forwarded to the firewalls DNS server which then again sends the faked response.


What are the advantages of cloud-based firewalls?

Depending on the type product you are asking about and the environment you are trying to defend there are several pluses and minuses.

Some potential pluses depending on the product:

Pluses:

1.) This isn't the norm but if you are talking about managed firewall services the product may have integration with larger analytic databases which allow the company to see a lot more traffic and respond faster to new attacks than a typical individual organization would.

2.) Anti-DDoS / Anti-DoS capability, again this really depends on the product/company (you didn't specify) but some third parties companies have multiple large connections to the Internet where they can build unique defenses against DDoS and DoS attacks and also have specialized infrastructure to leverage different DNS and BGP security components to reduce large-scale attacks. (This is a huge topic)

3.) The two above do not typically apply to basic cloud-compute firewalls (again I'm not sure which you are asking about) but in the case of some cloud services like Amazon's AWS there is better integration for whats known as elastic services where you can start and stop servers as needed and the firewalls "can" be automatically configured dynamically. This can be done on non-cloud firewalls but it's MUCH easier to do this type of orchestration in cloud-based environments designed around this task.

4.) If it's a managed service that has 24x7 teams and your organization is not staffed 24x7 this could be a huge benefit but do note that many cloud compute platforms leave all the security up to the end user so this answer really depends on which type of service you are talking about (could be a plus or a minus depending on the product).

Minuses:

1.) It's harder to see when things are misconfigured such that data can leave the organization. Note: I'm not saying this isn't manageable but lots of people new to cloud compute environments make many mistakes such that wouldn't have happened when all the data is forced through a physical cable that people can see.

2.) Hypervisor flaws underneath the firewalls may create risks to an entire environment in a cloud compute environment. There are other more interesting CVE's but as an example a recent one affecting some cloud compute providers is CVE-2016-5363

3.) A third party has access to all of your traffic and can control your security configurations. Weaknesses in the third party network are now weaknesses in your network. This can increase your attack surface dramatically.

4.) In most cloud compute environments you lose access to infrastructure-based NetFlow, or it's harder to get, or the data is not complete especially if your environment uses any serverless compute services. Some people add this back on at the host level but if the host's kernel is compromised it's TCP/IP stack may not be reporting malicious communications which then won't be accurately reflected in your NetFlow. Out of band NetFlow is a more accurate measurement specifically due to this issue.

5.) Capability to change hardware/software in an emergency is reduced. If your cloud-based firewall goes down there may not be anything you can do about it until the provider can correct the issue.

6.) You are outsourcing this security work to an organization who will not care about your data or your business as much as you do. Not a horrible thing but something to keep in mind.

There are many other smaller pluses and minuses but I'd need to know more about the specific system or service you are asking about. Likewise depending on the product or specific cloud platform (depending on which you are talking about) there may also be a lot of other issues that you will want to consider which are unique to that platform. Far too many to go into detail here.

The choice between the two is based on what you are trying to defend, the specific risks to your organization, and the trade off of any advantages either one brings to the decision.

Both cloud and traditional solutions can be really good but they are very different and they require good integration into your environment. These aren't products that you buy and just forget about.

It's always important to look at the security problem as a whole and see how these components fit your organization and what you are trying to achieve.

To answer your "speed" question. If and only if you are talking about having a cloud-based firewall in front of a traditional network there can actually be really big speed increases as some of the companies who do this have faster, lower-latency connections to the Internet backbone and they can cache content locally. This has the effect of moving parts of your services or services your organization is accessing closer to your users. Similarly they may add compression where it's supported by the various clients accessing the servers (this is a smaller issue speed-wise as most people configure their servers to do this but where that was not done their will be a speed increase). Some companies like Imperva can also cache content for you and act as a Content Delivery Network (CDN) which will give you additional speed improvements. But a lot of this depends on what your situation is.

Generally there are benefits in the form of the co-op model in that a large company offering these services can bring more technology to the solution than a smaller individual organization would tend to buy on their own. None the less for high-security data this may not be worth the additional risks.

I'll also mention that some organizations use both as a way to get the best of both worlds. I like this when it's appropriate.

Finally I need to mention that this answer is also very time sensitive as that market is still emerging so the pluses and minuses will change a lot over time.


Why do I have to use multiple keys for each direction and purpose?

In general, you should never use the same key for two different algorithms, because it makes related key attacks possible. That's why best practice is to use a KDF to generate separate keys for encryption and authentication operations. You can, of course, use an authenticated encryption mode, which will avoid the need to use two separate keys.

As to using different keys for different directions in a channel, while reducing your exposure to cryptographic vulnerabilities is certainly a concern, there is a much more fundamental reason: reflection attacks. Unless there is a clearly defined difference between what is a valid message for each of the two parties in a communication, an attacker can simply repeat what you say back to you to cause unexpected behavior. If the same key is used in both directions, what you transmit will pass your own authentication checks for incoming data, and then code that's expecting a guarantee of a secure channel will suddenly be dealing with unexpected invalid input. This can cause crashes or other unexpected behavior.

You can mitigate this at the protocol level by sending a message saying which side of the communication you are, but that adds parsing complexity just to mitigate a vulnerability, and that's really the job of the security layer. Using different keys for both ends of the connection avoids the problem entirely and is usually simpler to implement as well.


Emailing 2-Factor Authentication Secret Key

There exists a protocol called Dynamic Symmetric Key Provisioning Protocol (DSKPP). This is a client-server protocol which allows you initialise your authenticator with a secret key without emailing it - http://www.rfc-base.org/txt/rfc-6063.txt


In most cases the UEFI sits in a non-volatile memory (e.g. Nand memory embedded into the mother-board) , a good approach for such protection against FW compromise may be :

BEFORE first writing of the UEFI FW:

1.calculate RSA singature - has to be a strong implementation of RSA (e.g. 4096 modulus length + OAEP padding scheme)

2.Store both public key and signature concatenated to the FW image

3.if there is an option to use OTP memory block(considerably low-cost HW) - provision SHA-512 of the public key to OTP(optional)

On each loading of FW:

1.Verify SHA-512 of the public key concatenated to the FW image(optional)

2.Authenticate RSA signature

3.proceed with boot

This approach is fairly secured and not very expensive since RSA signature authentication will not consume much time (public exponent has few bits in it and thus the exponentiation will be fast enough).
I didn't find any such scheme in the secured boot specification , I hope that they will add something of that kind in the future.


Your code is wrong:

#include <stdio.h>

int main(){
    char *buffer[64];
    gets(buffer);
    return 0;
}

The char *buffer[64] creates an array of pointers to chars.

Try again with this:

#include <stdio.h>

int main(){
    char buffer[64];
    gets(buffer);
    return 0;
}

Run it at IDEone.

Actually, I can see quite a few reasons why this didn't work. Let's follow through your assembly:

   0x8048416 <main+43>: mov    ecx,DWORD PTR [ebp-0x4]

Since ebp-0x4 is a location within your input buffer, ecx is loaded with 0x41414141.

   0x8048419 <main+46>: leave

This clears the current stack frame, basically setting esp to ebp, then pops the top value off the stack into ebp to restore the previous frame pointer. You can again see that ebp was set to 0x41414141, because the top item in the stack was still part of your buffer.

   0x804841a <main+47>: lea    esp,[ecx-0x4]

This loads the effective address of ecx-0x4 into esp. Think of lea like a convenient pointer math instruction. In this case it's literally just doing esp = ecx - 0x4. This is why your esp value is 0x4141413d.

=> 0x804841d <main+50>: ret

A ret instruction sets eip to the top value in the stack. The problem here is that your stack pointer is set to invalid memory. You overwrote it with 0x4141413d.

Why did this happen? Your payload is almost certainly too long, for a start, but there's a difference in the assembly between what your code does and what the example code did. However, there's a silver lining: you have control of the stack pointer immediately before a ret instruction. This means you only have to point esp at some memory you control, and you get eip control.

What you want to do is run the code until you get to <main+43>, then work out offset in your payload has been placed at ebp+0x4. You can make this a bit easier using a tool such as Metasploit's pattern_create.rb, but just observing the values in the stack should be sufficient to work it out manually.

So, let's imagine that 80 bytes into your payload is where the application reads that value from. Your payload now wants to start with 'A' * 80. After this, encode the address of the stack minus 8 bytes into the payload. So, if the stack pointer at that point was 0x4120EC40, subtract 8 to get 0x4120EC38, then place \x41\x20\xEC\x38 into your payload after all the A values.

When you next run the program, what should happen is this:

0x8048416 <main+43>: mov    ecx,DWORD PTR [ebp-0x4]
; [ebp-0x4] contains an address slightly further up the stack (0x4120EC38)
; all the memory around this address contains 0x41414141
0x8048419 <main+46>: leave
; leave the stack frame, setting esp and popping ebp
; both registers are trashed but it doesn't matter
0x804841a <main+47>: lea    esp,[ecx-0x4]
; subtract 4 from 0x4120EC38, giving us 0x4120EC34
; then set esp to this value - [esp] is now 0x41414141
0x804841d <main+50>: ret
; pop the top value off the stack and set eip to it
; eip is now 0x41414141

You win.

As an addendum, you may run into the problem that you can't encode the stack address into your payload because it contaisn a null byte. You can get round this by shortening your payload so that it only partially overwrites the stack frame pointer, so you can change the least significant byte (or two bytes) allowing partial control over esp to point it further up the stack, rather than totally overwriting it.


Store private key on server, then use k1 to log in, k2 to verify HMAC and k3 to decrypt private key

There's a couple of problems:

1 - In the log in sequence - step #4 - you are sending k1 for verification at the server.  The server does not have a copy of k1.  According to the account creation thread, step 3 (generate k1, k2, k3) occurred presumably client side, and were not part of the server transmission (step 7)

2 - If you store k1, then it's effectively a password - repetition of the k1 value is all that is required to get to login step 4.

3 - The thing that is standing between the attacker and the ability to imitate the user is the AES 128 bit encryption of the private key.  It's stored on the server, and so if the server is cracked the encrypted key is obtainable. If you also offer k1, you might offer the ability to get added data. There's basically two possible calculations that the attacker can compute at until he finds a winning combo:

AES decrypt( test-k3, encrypted private key) = creates a key that can decrypt any encrypted email.
key gen with PBDKF2-HMAC-SHA512 (salt, # interations, test-password) = k1 (known), k2 (unknown), k3 (unknown)

Now we're into the realm where the question is "how easy are those things?" and I really don't know.  That's a good question for crypto.SE - we're into the world of cryptography difficulty, which isn't my strong suit.

4 - don't negate the value of watching transmissions and colocation of servers.  If the attacher has hacked the account/login server, what else is located on that server?  If it's also serving email, or post-authentication privileged user transations - your problem isn't the steps above, it's the other high-value assets.  Also - watching when a user logs in, and their general pattern of behavior, trials and errors will give enough social engineering information that the annoyingly mathematical part of cryptographic hacking is irrelevant.  If I can break the server, call the user and apologize, and get him to tell me his password over the phone, the work of hacking the crypto is obsolete.


On my MacBook, is my user password now the Achilles heel of disk encryption?

OS X Lion included a major rewrite and redesign of FileVault, that may be the change you are looking at. Legacy FileVault (the old version) continued to work in Lion and even Yosemite if you did an upgrade in place; maybe you did a clean install last time, or got a new machine?

FireVault 2 is a significant upgrade to Legacy FileVault and the general advice is that you should upgrade.  You are correct that you will need to have a decent user password, but the thing is that you need to have a decent user password anyway!

FDE is only for protecting the machine when it is turned off; when it is turned on the OS has to protect the machine and it can't do that if you have a weak admin password.

However, you might be over-estimating the strength you need in your password. There was an interesting paper published in 2002 that estimated it would take about 34 years to brute-force a FileVault 2 password with 32 bits of entropy; that is
actually a fairly modest password I would say. You only need three Diceware words or a 7 character random alphanumeric to get 32 bits.

You can't revert back to Legacy FileVault. However, you can get a very similar set-up to what you had before by simply keeping all your sensitive data in an encrypted sparsebundle image. This way, you get all the benefits of FileVault 2, but your data is also encrypted with a very long passphrase that you only need to type in once per session.


Modern day version:

Use HTTPS for your entire site, including the marketing pages. Add the HSTS header.
If your target audience is computer savvy enough, then avoid the traditional username & password login completely. Offload that to a good federated login system, such as multi-provider OpenID, or Facebook Connect or Google's login.
For the functionality on your site that has higher security needs (the important stuff) use CSRF tokens.


To be clear, to you as a member of an organization, a security incident is defined by your organization's security policy; it's not just "your personal opinion on what's risky" or "any event that puts the organization at risk".  Check with your organization, read their security policy, and follow its guidance.

If they don't have such a policy, and you're asking this question, that's a sign they may need one.

In the absence of a policy, you should consider it from your own point of view.  If you found a vulnerability, or possible evidence of an attack, you should document it and report it to your supervisor as quickly as possible.  It's the job of management to decide what's risky and what isn't, not you.  If you don't report it, and the problem turns out to be serious enough to involve the courts, there will be a lawsuit.  The first two things the lawyers are going to want to know is "who knew about this, and when did they know about it?"  If they find you learned about the incident but didn't report it, the legal mess could ruin you.

And once you've reported it upwards, you've discharged your duty.  If they decide not to act on it, that's their decision; even if it seems foolish or risky to you for them to ignore it.  Just make sure you've documented the incident so that people can understand you did what was reasonable given the circumstances you were in, and informed the correct person or people.

The same goes if you're a supervisor or manager, and an employee informs you of a risky or dangerous situation.  You need to report it as per your organization's security policy, or report it upwards if you don't have one.


How could an AV detect a virus that has a chance of not decrypting itself?

What the article says is that the virus contains a lot of specific code aimed at defeating anti-virus -- both the AV software itself, and the analysis techniques used by AV developers to figure out what the virus does. In the specific paragraph you quote, that's the latter which is discussed: the virus code alters its behaviour when it detects that it is running in an emulator.

Theoretically, a virus can always be defeated by a human being following the code "by hand". However, it is tiresome and takes quite some time. In practice, AV companies have nowhere near the time and resources to do manual analysis of every new brand of virus, which is why they need to rely on some semi-automatic techniques such as emulators. This is a losing battle in the long run...

Obligatory rant: a computer virus can exist and strive only because of flaws in the structure or implementation of computer systems -- in particular indulging in execution of code of dubious provenance. An example of a system which is well designed in that matter is a Linux distribution: executable files may come only as packages from official repositories, and the provenance is controlled with signatures. It is not "perfect" but the rarity of virus in the Linux ecosystem is suggestive that they do something right at some point. The best defence against virus is to fix the flaws. AV are like a new layer of paint to hide the crevices.


Attacking WPA/WPA2 ; Clarification on deauthentication packets

Only one four way authentication exchange is required. You can either wait for it or send a single deauth pack to a connected client so that it would re initiate the connection. The reason why they use multiple deauth could be the low SNR of the network. In order to successfully deauthenticate they might need multiple packets as some might get dropped.


Does read-only access to the database prevent sql injection?

No.  You might be confusing SQL injection with data injection; read-only tables do not prevent SQL injection and at best do only a little to limit its impact.

SQL injection simply means the ability to inject SQL code.  While read-only tables may limit the ability to inject data into the table, they don't impact the ability to:

Read from other databases or tables if not disallowed
Read from system tables or run other system queries which are hard to disallow
Write excessively complex queries that will perform a DoS
Exfiltrate data using DNS
Access local files (e.g., utl_file in Oracle)
Access the DB server's network (e.g., utl_http in Oracle)
Execute arbitrary code on the server via DB function buffer overflows
See Advanced SQL Injection in Oracle databases for a good walk through all the sorts of things you need to worry about (and realize other databases have their equivalents)

If you

  basically just want to tack what they enter onto the select statement.

then you're expressly permitting the attacker to try any of these.

Now, you can certainly do things to limit this.  You can disallow quotes and SQL statement separator characters.  You can disallow any input that's not [A-Za-z0-9"=] (or effectively equivalent for your database).  But if you start going down this path, you're better off writing your application correctly: Expose a richer query interface where you offer the keys to be checked and then you perform proper quoting on whatever values the user enters.


Attacking (or even pinging) a device over a network on different VLAN

If the firewall which defines the VLANs is configured not to allow traffic between the VLANs then the answer is that you can't unless the firewall is in some way misconfigured. That's part of the reason for having VLANs in the first place.

However routes may exist for some specific traffic from VLAN to VLAN, or between devices on different VLANs, but they need to be configured as such in the firewall.

From personal experience I've seen TCP traffic controlled between VLANs but not UDP, and also ICMP sometimes allowed between, but this is due to the firewall config.

This is not the same as possible ARP flooding switches to force a switch to revert to a broadcast hub to gain access to different areas of a switched LAN, firewalls don't (shouldn't) downgrade this way when under extreme stress. However, it's worth checking whether any vulnerabilities for the VLAN managing firewall exist that can be exploited to overcome VPAN separation controls.


How secure is the PwdHash algorithm and system?

Having unique passwords entered to every site IS safer than giving each site the same password, for exactly the independent-compromise reason you suggested.

  If an attacker has the hash, and knows that it was generated with PwdHash and knows the domain that it was generated for, how feasible would it be for them to determine the original password from that?

Well, let's do some investigation and some math!  PwdHash appears to be using effectively GoofyStuff(Base64(HMAC-MD5())), so we're at the usual MD5(MD5()) guessing game speeds.  Per oclHashcat, "PC5 (8x AMD R9 290Xstock core clock)" can crack ~81 Billion MD5's per second, so ~40 billion tries as PwdHash per second, which gives us the more practical 1E17 (somewhat over 2^56) tries per 30 days.

I base the above on this snippet from a quick glance at the PwdHash page source:

    var hash = b64_hmac_md5(password, realm);

This is in the range of an exhaustive keyspace search of 62^9 to 62^10 in those 30 days, where 62 is the keyspace of upper case, lower case, and numbers (or upper case, lower case, and the symbols above numbers, whichever you like), and 9 or 10 is the length.

Thus, a fully random upper case, lower case, numeric password encoded with HMAC-MD5 will be found in less than about 30 days (unless you and the attacker are using different character sets (i.e. Cryllic vs. English)).  You'll need something with a larger total keyspace than this for your master password, and that's if it's a truly random password!

You don't even want to think about what a rules based dictionary attack can come up with at this speed, if your password is not, in fact, fully random.  My most comprehensive wordlist set is over 40GB of unique passwords; if we assume an average word length of 9 plus a LF separator, that's 4E9 words, meaning that if an attacker with that PC spent 30 days on your password, they'd be able to try roughly 2.5E7, i.e. 25 million different variations (rules) for each password.

Note that this wordlist is too slow and cumbersome to bother with... unless the target can be attacked at insane speeds, like a single HMAC-MD5 can.

If you do use PwdHash with a master password, have a really, really good one - 15 character or better, cryptographically random, with a large character set (upper, lower, number, symbols above numbers, symbols not above numbers).

  Other considerations

You should think about how you're going to change your master password after it leaks; perhaps you're up late and are trying to hurry and you type the master password into a web site directly instead of into PwdHash, just by habit, caffeine deprivation, hurry, and carelessness.  Now you need to change it!

Personally, I like offline password storage like KeePass, but I'd much rather use even basic OpenSSL than PwdHash - AS PATHETICALLY INSUFFICIENT AS IT IS, I'll put HMAC-SHA-512 up against HMAC-MD5 any day of the week.

 echo example.com2014 | openssl dgst -sha512 -hmac MyPassword -binary | openssl enc -base64

As always, you're better off using something truly random and storing it, or, if you insist on a deterministic generation routine, something really, really slow - particularly since this is just for you, so PBKDF2/BCrypt/Scrypt with enough iterations/work factor that takes even a second or two or five on your machine would be just fine, and would slow down an attacker to a crawl.

Shameless plug: I'm working on collecting a variety of PBKDF2 (and hopefully later BCrypt and Scrypt) code examples at my Anti-weakpasswords github page, some of which compile so you can run them at the command line of Windows or Linux, and use them exactly the way you're using PwdHash now, but with a higher iteration count than almost any website could use, if you're willing to wait a couple seconds.  As of today, there's only a Python version that Mitsuhiko wrote and Warner fixed for high iteration counts, not yet updated with better hashes, but that'll improve.


Is this Paypal Github SDK reference really a dangerous site?

No, it's not dangerous at all. Your browser is warning you because a non-Paypal website has Paypal in its name. This is a common technique used by phishing sites that attempt to fool you into thinking the site is official. For example, a website might be called paypal.secure1234.com and made to look like the official site, enticing you to trust it and input your sensitive credentials. The browser has no way of knowing that the site you are visiting has Paypal in its name for completely benign reasons.


Security of setting access to S3 bucket only from a particular website

Your intuition is correct in the most important way -- this is not, in any meaningful sense, "secure."

But the way it's defeated is not quite what you envision.

When you click a link on a web page, or your browser loads an image embedded in a page, your browser connects to the web server and sends a request.  In the request are the HTTP headers, including one called Referer:.  While not always present (for various reasons that may be outside the scope of this answer), the accompanying value is the URL of the page you were looking at -- in the same browser tab -- when the link was clicked or the image was loaded.

Creating such a policy in S3 implements access control by string-matching this value, submitted by the browser, and almost entirely devoid of any value from a security perspectice.

So Javascript in another tab while your page is open isn't really the concern.  The concern is a malicious user crafting requests with a forged Referer: header -- easily done with test tools like curl (curl -v http://example-bucket.s3.amazonaws.com/secret-image.jpg -H 'Referer: http://example.com/good-guy.html') or browser plugins.  Now the bucket says "oh, you're on the Good Guy page from example.com? Here's that secret image file you asked for."

So with such an obvious limitation, what is this mechanism actually useful for?

Not securing your content.

It is, however, useful to prevent widespread hotlinking to your content, embedding links to your assets in third party sites, which amounts to theft of your bandwidth.  I once encountered a scam site where the creator had googled for pages showing pictures of gift cards.  He found such images on one of my sites, but he didn't download them... he embedded links to my images into his scammy HTML.  A configuration denying on referer significantly reduces such annoyances... but as it is  suitable for very little else.

With S3, you can generate signed URLs on the fly (assuming your site is dynamic) and embed them in the html.  This is perhaps the most effective solution, since you specify the period of time for which the URL is valid, and these URLs are immune to tampering to the point of computational infeasibility.  CloudFront, in conjunction with S3, allows you to create signed cookies that accomplish similar results but without needing to sign each individual link in each page you render, but individual signed URLs for objects with a very short expiration time, using HTTPS and delivered over HTTPS are an effective mechanism of access control, unlike referring page policies.


Could data be recovered from cut magnetic stripe card?

As a former developer for one of the biggest Security Card System organizations in the world, I can confirm with you that the answer is resounding YES depending on the manufacturer and the type of the card.

For example, my company used the standard ISO encoding standard for magnetic stripes for Debit cards, and quite frankly there is not much confidential information in magnetic stripes of the sort to begin with. The encoding is ISO standard, and you can actually search for it online. I included a link to Wikipedia , which is obviously unreliable but that generally holds true. As you can see, there is not much confidential information on the magnetic stripes aside from the name or card number – both of which can be read directly from looking at the card. These information are repeated throughout the stripe maybe twice or three times. The start and end sentinels typically appear just once.

At any rate, some institutions (mostly EMV bound ones) request this data to be lightly encrypted based on EMV standards and appear just once – and as you may have noticed, I said EMV (Visa, MasterCard, AMEX) – so you will never find this on debit cards (unless they are Visa/MS debits).  You may or may not be able to extract the data from these types of cards – that would depend on what is lost at the cutoff point. Not all credit cards magnetic stripe info are encrypted – just select ones.


How to filter PCAP for TLS "application data" packets?

I've checked the provided pcap file and counted the used ContentType's in the SSL traffic:

$ tshark -O ssl -r youtube_song_wireshark.pcap tcp.port == 443 |\
grep 'Content Type' | sort | uniq -c

This gives me 64 x Alert(21), 86 x ChangeCipherSpec(20), 362 x Handshake(22), 2188 x ApplicationData(23). It does not give any of the ContentType's you've seen in your analysis.

In a comment you provide the following snippet of the results returned by your scapy based analysis:

<SSL records=[<TLSRecord content_type=51 version=0x70c2 length=0x3c44 |<TLSCiphertext ...>

Given that there is no SSL/TLS version 0x70c2 but that the version should be in the range of 0x0300 (SSL 3.0) to 0x0303 (TLS 1.2) I suspect that you parse data as SSL which are not SSL at all and that you get such a strange result then. There is several non-SSL traffic in the pcap you've provided.


How can I detect users that have requested AD Administrators to reuse an expired password?

There is more than one way to configure auditing in Group Policy, but I think the primary old way (on Windows Server 2003) is to open GPMC, edit the Default Domain Policy (or whatever domain policies are active in the OU and objects you're working with), and drill down from the Policies node through Windows Settings to Security Settings, in order to open the Local Policies Audit Policy branch. There's an "Audit account management" section that you can define.

The above only lets you audit the account changes, but you have to make it actionable by relating it back to success criteria, such as a user's password had recently expired. By leveraging OSSIM (or another strong correlation engine), you could combine ADSI scripts which check every audit account management message to see if it was a password change, and to see if the password recently expired. Then, the hashes could be matched, etc. Even OpenVAS could be kicked off to try and bruteforce the password -- although it would probably be better to perform this task with more data.

This becomes an exercise in customization for client, server, and other infrastructure hardening/monitoring. You would want to move the maturity of your entire infrastructure to a higher level -- so I assume you've already done much of the work prescribed by The Center for Internet Security (CIS) and/or NIST.

If you are more greenfield and haven't implemented customized solutions like this in the past, it would certainly be better to jump to a future-proof solution such as OpenIDM from ForgeRock. This would be a multi-million dollar, six year project or so.

If you're in a large-installation brownfield operation, such as Fortune 500 -- it would be best to identify your existing IAM, IDM, Directory, ESB, and other backoffice components in order to properly analyze where to fit identity lifecycle management issues such as user-password resets. It may be that an existing solution provider, such as SAP, Oracle, TIBCO, or Microsoft has an easy answer.

If you're solely a Microsoft shop (100 percent), then you probably want to discuss their ILM 2007 product, FIM 2010, and related solutions. Microsoft has a nasty way of canceling these product lines, or changing them drastically -- so it's good to be hip to the "inside track" and discuss directly with the ILM/FIM and other product managers (PMs) instead of just an account manager (AM) or their websites and trade information.

There are other, more point solutions such as Quest software's ChangeAuditor for AD, but I would be wary of this only solving a short-term problem, when clearly a business process and huge set of business/infrastructure maturity problems may exist.


users avatar names based on Primary Key, is it safe?

Assuming (a) primary key isn't a secret in any way and (b) primary key is limited to filename-safe characters (which looks to be the case here as it's numeric), yeah, that's fine.

Naturally there are other security concerns with the content of user-uploaded images as outlined in previous questions.

The only other potential gotcha I can think of if you're moving this from a database BLOB implementation is that the database may be transaction-safe but the filesystem won't be. But as long as your application doesn't fall over when there's an avatar file missing that shouldn't be an issue.


Load balancer and two machines - how many SSL certificates do I need?

The point of a load-balancer is that all your servers appear to the client as one. So no matter where you handle the TLS (on the load-balancer or on the application servers), you will only need one certificate to ensure that no web browsers will show any HTTPS warnings.

When clients communicate only with the load-balancer (which handles TLS) and you control the network between the load-balancer and the backend servers, there is little reason to encrypt that connection too. But when you do not trust the network and want to use encryption between load-balancer and backend servers, you can use self-signed certificates for that. When you put the certificate on the servers yourself, you know they are trustworthy. So paying a 3rd party to sign them would be pretty superfluous.


Don't spend a lot of money on this effort, because any software you distribute can be  cracked.  Unless you're distributing expensive hardware keys, or creating a server-side component, any end-user copy protection scheme can be broken.

Instead, you can make it complex enough to thwart most people (it sounds like you've already done this.) Also, you could appeal to your users to be trustworthy and not to share copies.  Relying on a service to perform an important feature works for products like Microsoft's Office365.


Following redirects from HTTPS to HTTP - Secure?

A redirect is when the server responds to the client: "to get what you look for, you must ask again as that URL". If the POST target, from the client, is an https URL, then the request and the response will be protected by SSL. In particular, SSL protects against "injection" by an attacker of a "redirect" response.

However, if the SSL server really wishes to redirect the client to a non-SSL address, then the client will do just that, and send its POST again, this time with plain HTTP. This second sending, being unprotected, is vulnerable to all the usual attacks since it is not protected: eavesdropping, alteration, misdirection...

It is like living in a bunker, then stepping outside. You decide, securely, to exit the bunker; and you take that decision while you are still in the bunker. But, once outside, anything goes.


How to figure out if someone has been using TeamViewer 8 to access my computer when I was not here?

Running Teamviewer isn't very secure: read here

To determine who was logged in - look here:

C:\Program Files\TeamViewer\VersionX\Connections_incoming.txt
C:\Users\XXX\AppData\Roaming\TeamViewer\Connections.txt


What is the risk of reusing the ATM Pin elsewhere when they tie to EMV cards?

Intercepting the pin on the internet, and knowing it's the same as the card PIN would leave you more susceptible of a targeted attack aiming at procuring the card.

Granted that if the PIN can be intercepted, then most likely the other credentials are as well, and the attacker could perform an attack on the banking site.

Bottom line, don't put user at physical risk.


Can the Internet Achive capture anything malicious?

The Internet Archive stores whatever was on that site at the time it crawled it so yes, there could be malicious code there. I understand they make some checks, but you should always assume that it is as malicious as a current site, although likely with older malware :-)


wlan security - why is it not possible to protect against deauthentication flooding

Authentication and de-authentication is written into the protocol at a lower level than the encryption. It is the same regardless of whether you use WEP, WPA, or nothing at all.

The risk here is denial of service. A lot of de-auths can mean a lot of re-auths and that can chew things up. Properly implemented and using a good key, the encryption should not be at risk regardless of how many times the encryption is setup.

De-authing is a convenience for the attacker, but it is reasonable to assume that in a 24 hour period somebody will authenticate. If your attacker is interested in something beyond easy internet access, they'll get it.

This isn't the only case you'll find like this. SSL on TCP/IP has the same vulnerability -- the TCP flags, including the RST flag, are plaintext. How else do you tell somebody to end a connection if your system gets out of sync with their system?


Can a MITM sniff and see TeamViewer's session?

Team Viewer's website provides the answer to your question.

  TeamViewer includes encryption based on 2048 RSA private-/public key
  exchange and AES (256 bit) session encryption. This technology is
  based on the same standards as https/SSL and meets today's standards
  for security. The key exchange also guarantees full, client-to-client
  data protection. This means that even our routing servers are not able
  to read the data stream.


Trying To Set Up An SFTP Server Securely On a Synology NAS? Any Advice?

The generally accepted option is a VPN. To make it more secure (additional layer) you could use that VPN to access a jump box, a machine that can then be used to access the FTP service after logging in to it. I would suggest a full tunnel VPN and a jump box that allows you to upload files, maybe using a client like FileZilla. I would suggest that you do not use any RDP services directly on the internet.


Is emulated SQL query preparation less secure?

The only currently known SQL injection vulnerability in PDO parameterized prepared statements using the default of emulating prepared statements is if the client's and server's locale is out of sync.

Since locale is negotiated during the initial connection setup, and persists for that connection even if the server's default is changed, in order to get the locale out of sync, you need to have a successful Man-in-the-Middle attack.  And if you do have a MitM attack, then the emulated prepared statements mode is the least of your worries, as the attacker can send any arbitrary commands and responses, without needing to go through the trouble of SQL injections.

While theoretically, there may be a slight decrease in security from using emulated prepared statements, there is no practical difference since exploiting the emulated mode requires pwning the connection anyways.

Still, there is very little practical benefit from leaving the emulated mode on, and if you ever get to a point where that tradeoff matters, your site will have already faced several other scaling issues, and you'll know how to do the necessary research to make the best choice for your system.  It won't hurt to turn emulated mode off, in the sake of security... but it won't help either, and anyone who tells you one way or another without a thorough understanding is engaging in cargo cult programming.

Also, if you're still paranoid (which the people here who answer security questions tend to see as the only sane state of mind), know that the PDO emulation of prepared statements only applies to the MySQL client engine.  Other database client engines in PDO, such as PostgreSQL, never emulate prepared statements.


Is it safe to host passwordless web applications/software with web GUI in Virtual Machines

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

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

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


XSS with escaped equal sign inside jQuery selector

You would maybe be able to do it if the charset was not atypical, and then you may be able to get a valid result by using a multibyte character converting into an equals sign, but you can't change the charset yourself as it will probably appear in the server response header, or default to UTF-8.

In Section 12.1.2.1-3 of the HTML standards, tags have to be closed by U+003E so using script tags will not work.  Attributes can be specified by an empty syntax, such as 'disabled', but none of these will allow you to execute JavaScript.  You can use unquoted value syntax, as you've pointed out in your question, but the unquoted part must follow a U+003D sign, as it does for single or double quoted attributes, meaning there's no avenue left to exploit.


PCI DSS 3.2 SAQ A and SAQ A-EP - 2 different web shops

As I see, there are two web shops of the same company in scope where one has hosted its website in their own data center while other one has hosted on cloud (Azure). Since the first webshop uses iFrame to load pages of PCI-compliant 3rd party payment service provider, irrespective of where it has hosted its web it requires only SAQ A and quarterly ASV scans are absolutely optional. But in case of second webshop hosted in cloud that redirects card data to third party with https POST, not only SAQ-EP and quarterly ASV scans are required but also internal VA scans on quarterly basis and external penetration test at least annually are required as per the current PCI DSS standard v3.2. Since most of the leading cloud service providers are already complying to a number of international security standards you can ask for copy of their PCI certificate which is fair enough for SAQ-EP requirements.


Is it better to rate limit API requests based on UserId or IP address for authenticated users?

I would say it depends. In generall IP blocking is a good practice because the IP is the only identifier that exists for anonymous users. But keep in mind that a user can "switch" IPs using online proxy services AND on the other hand that maybe multiple users share an identical IP when they use a proxy server (which ist often the case in enterprise environments).

If your users are authenticated then you should block the userId when the user is doing malicious stuff.

Another aspect, how easy is it for an anonymous user to create a new account in your app? When he can create new accounts without a problem, then blocking userIds is useless, because when the attackers user 1 ist blocked, He easily can create a new user.

So you should rely on both techniqus and check how easy it is for an individual to create new accounts.


Why didn't OSes securely delete files right from the beginning? And why do they still not do this?

Because of the following reasons:

Performance - it takes up resources destroying files. Imagine an application that uses hundreds or thousands of files. It would be a huge operation to securely delete each one.
Extra wear and tear on the drives.
Sometimes the ability to retrieve a file is a feature of the OS (e.g. Trash, Recycle Bin, Volume Shadow Copy).
As noted by Xander, sometimes the physical storage mechanism is abstracted from the OS (e.g. SSDs or network drives).


How secure is PIN code + substitution authentication?

It's not secure, because there are only 26 ^ 4 possible solutions. This can be brute-forced. If the picture includes capitals, we can increase this, but even 52 ^ 4 is a very small search space.

I'm assuming that it gives you a different picture at every logon attempt, but that does not effectively make the search space smaller.

However, there is one advantage to this scheme - it prevents replay. You will enter a different letter combination every time, so if an eavesdropper intercepts your input, they can't use that combination again.

Unfortunately, that assumes that the attacker gets your input but not the picture. This is an unlikely scenario, an eavesdropper (whether MITM or shoulder-surfing) is likely to get both. It does offer a little protection if all the attacker has is a keylogger on your system.

So, this is an interesting idea to prevent replay, but poorly executed.


Usually, such networks are behind Network Address Translation (NAT). NAT waits for an internal system to send out a packet to a WAN address, then stores the route in a table. It alters the packet to have the router's WAN IP as the source address, and sends it to the internet. When the response comes back, it matches the incoming packet to a route. This is especially easy to demonstrate with TCP, where a connection has a sequence number that can be used to match the packets to the conversation.

The problem with accessing internal ports is that if a packet doesn't explicitly match a route that the router knows about, it is dropped. Note that port forwarding rules create their own routes, so the router knows to route incoming TCP / UDP packets to a particular internal IP. As such, it's quite difficult to enumerate internal IPs from the internet, let alone do port scans.

The only way I know of to do this is to exploit the router. Some of them have badly set up UPnP daemons, allowing you to trick the router into setting up port forwarding rules. There are some other ways to do this, usually via the router's control panel.

Aaron "finux" Finnon (@f1nux on Twitter) did a great talk about pwning UPnP at BSidesLondon earlier this year: http://www.securitytube.net/video/4140


What is the difference between a key algorithm and the encryption algorithm?

OpenPGP uses a hybrid encryption approach. Public-key encryption (commonly, RSA is used, but there are also other algorithms) has the advantage of a different public and private key set, but is getting really slow over time.

The public key is the one used for encrypting to the recipient, who can decrypt using his private key. This public key is usually referred to as the "OpenPGP key" of a person, most of the time specified as "public OpenPGP key". This is what you call a "key algorithm".

Assymetric encryption algorithms like RSA have one disadvantage. This is why OpenPGP additionally uses symmetric encryption algorithms like AES (and others): these are very fast for encrypting large sets of data, but both sides must agree on a key. To do so, whenever you're encrypting something to an OpenPGP user, a new random, symmetric key is created, and encrypted using the recipient's public key (so he can read it). This might be called "encryption algorithm", but is no common wording. In the end, both the asymmetric and symmetric algorithms are cryptographic algorithms.

Choosing from the possible algorithms depends on which are supported by the OpenPGP implementations used. Usually, you don't have to do anything, and your OpenPGP implementation (eg. GnuPG or PGP) will choose the appropriate settings for you, given the public key of the recipient is available. If one of you is using very old implementations you might to modify these settings; but it would be more recommended to switch to a more recent one.


How secure is isolated storage on Windows?

You should look at the .net SecureString class if you are worried about storing data in RAM: http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx

Here is some important info about isolated storage: http://msdn.microsoft.com/en-us/library/3ak841sy.aspx

  Although isolated storage is well suited to the scenarios described
  previously, there are a few cases in which you should not use isolated
  storage:

  Do not use isolated storage to store high-value secrets, such as
  unencrypted keys or passwords, because isolated storage is not
  protected from highly trusted code, from unmanaged code, or from
  trusted users of the computer.

Without knowing more about your application you might want to look at using DPAPI via the ProtectedMemory class.

This way you either secure the data based on the current user, or based on the current machine. Obviously if you can restrict it to the current user the data will be more safe.

So, Isolated storage provides a safe place to store data (you won't have to worry about overwriting other applications data, but it is not secure). ProtectedData will ensure that the data is secure where it is stored.

Hope that helps.

Ross


Web Applications terminate strings on null-byte

Actually PHP strings can contain null bytes; so can a .NET string (hence ASP.NET). At the PHP level, this byte is nothing special; the character U+0000 is just another Unicode code point. Trouble begins when the string is passed to another system, for which the null byte is a string terminator. In particular for file accesses: if the PHP code tries to open the file foo.txt\0.php (where \0 stands for a null byte), then the OS will only see a request for foo.txt, ignoring the rest of the string.

This is documented. In other languages as well.

In your case, one must assume that the bytes received as a "search string" are sent unmodified to an underlying search system for which the null byte has the special meaning of terminating the string. Though this is not a vulnerability in its own right, it is indicative of the Web site not filtering input characters, and that can lead to trouble.


Google says it's not a security problem and that you don't have to worry.
After investigation they issued a statement in the Google product forums:

What happened?
During routine maintenance [from 1pm to midnight PST yesterday], a number of users were signed-out from their Google accounts. This may have resulted in you being signed out of your account or seeing a notification about “A change in your Google account” or “Account Action Required.”
We hear your concerns that this appeared to potentially be phishing or another type of security issue. We can assure you that the security of your account was never in danger as a result of this issue. You can always learn more about the Security tools Google provides at www.google.com/safetycenter/
What should I do now?
First, try signing back in with your usual username and password at accounts.google.com. If you can’t remember your password or can’t sign in for another reason, recover your account here: g.co/recover.

Note that the statement only refers to this particular incident from around February 24th, 2017 which has affected many users and is likely harmless. But more generally, if Google is asking for a security confirmation or warning you about changed account details, you should take that seriously and review your security settings and recent logins - as you should do regularly anyways.


Is it a weakness to be able to see server side scripting?

I'm not sure how best to approach your question, other than saying "no, it's not a security issue". Abstraction has nothing to do with it. I'm not sure what your friend meant by it, but PHP does have abstraction (classes, inheritance, etc.) and doesn't require you to embed any HTML in your page at all. Modern PHP sites tend to have a data layer, a logic layer (usually facilitated by a set of classes that represent virtual objects on the site), and a presentation layer. CF likely has similar constructs.

One thing I will note (though I can't speak for CF) is that it's notoriously easy to write terrible PHP code, in part because it's so forgiving, and in part because most tutorials don't cover any basic security requirements.

However, here's a few reasons why PHP is considered "insecure" by some:

Silent type juggling, leads to difficult to spot logic errors.
Default configuration leaks information (displays errors, php_info and exec enabled, etc)
Tutorials for MySQL have a heavy dependance on mysql_query with string concatenation, rather than parameterized queries with PDO or MySQLi.
No in-built output filtering functions for XML, JavaScript, etc. The APIs for outputting safely to HTML aren't clear and simple, either.

However, no PHP code is transmitted to the client at any point. It is entirely server-side. It executes on the server, and outputs a result, which is usually HTML.

Don't get me wrong - I actually quite like PHP. It's easy to use, and (despite its quirks) can scale pretty well too. The problem is that it's too easy to write code. PHP makes it remarkably easy to introduce XSS, CSRF, LFI, RFI, SQLi, etc. into your code, because they don't document the potential risks alongside the API reference, nor do they provide obvious and standardised ways of approaching security issues.

My final point is this: languages aren't inherently insecure. Some may make it easy to write bad code but, in the end, it's the developer who created the insecurity, not the language.


What does it mean when a webpage says refresh is disabled?

Well, Mr. Gibson is a bit of a tool when it comes to security. The appropriate term is charlatan.

His secure pages cause the pages to be cached locally, so when you hit refresh it doesn't make a web request, but just pulls the html from local storage.

He didn't "disable" refreshing, he modified the default behaviour of a page request. You can still refresh the page, and you can make the request again.

It really doesn't do much for security because the sensitive stuff is now sitting in your cache for a really long time. It isn't any more secure than making the request again.


The basic idea is simple as you've mentioned, MITM works in ARP spoofing scenario as follows:

To perform MITM between A and B:

Trick A to think you're B
Trick B to think you're A
Enable packets forwarding

That's it! so regardless of your environment, whether it's a switch or hub or even a proxy server, the principle is same.

So, the answer to your question is: Yes. You have to perform the attack between the victim and the server that's run on the same network. And for each server you put on this network, you'll have to do the same.

PS:It's not a good idea, but you can use what's so called 'Hail Mary' ARP spoofing attack, basically you run ARP spoofing on all local devices and claiming to be one or more device. In that way, all the devices will be tricked to believe that the attacker is the server, the gateway and all other important machines.


OAuth2, microservices, and "keep me logged in" feature

First of all, determine if your services are confidential or not.

  Clients capable of maintaining the confidentiality of their
        credentials (e.g., client implemented on a secure server with
        restricted access to the client credentials), or capable of secure
        client authentication using other means.

So, for example Angular Application or Mobile Application are usually not confidential, but backend services are.

If your service is confidential, you can securely store refresh token for a quite a long time (like 30 days).
The full flow would be:

Register a client on Authorization server
Securely store client_id and client_secret on your service

After that you can authenticate users:

Authenticate a user
Get access and refresh tokens
Store refresh token securely
When accesstoken is expired, get a new one with refresh token

In that case you have short-lived access tokens and long-lived refresh tokens.

Access tokens that are valid for 30 days is a bad practice, they are usually issued  not more than for 8-12 hours.

If your service is not confidential, you can think about using some edge service or reverse proxy that will handle securely storing issues.

Regarding getting access to user information I will recommend to use OpenID Connect that is actually better suited for authentication purposes.
OpenID Connect is an authentication protocols that is built on top of OAuth2. Simplified it adds user identity API to the OAuth.

OpenID Connect adds an additional token to the Authorization server response( JWT ID Token) with minimal user information and specified /userinfo endpoint where the service can get additional user information.

To summarize the recommendations:

Use OpenID Connect for authentication
Use OAuth for service-to-service communications
Securely store client credentials andrefresh tokens
Use short-lived access tokens and long-lived refresh tokens


In NTFS EFS how is the symmetric key (FEK) generated?

FEK is random
Sorry. (But if it were any different, this would be terrible for EFS.)
Microsoft Corporation, TechNet, How EFS Works:

When you save a file to be encrypted, a random cryptographic generator supplies a unique file encryption key (FEK), which is a fast symmetric key designed for bulk encryption. The FEK encrypts the data in blocks.


How do i verify a banks contact number is correct?

If you cannot trust the phone company to route your phone call, do not use a phone.

If you are concerned about the number being legit, just ask for it in person at the bank, use official papers, cross-reference with a phone book and the website. Use your personal account space online to get the contact information.

If the bank is decent enough and the persons here well trained, they wouldn't share, confirm or denying personal information about yourself.


I'll try to explain this in terms of Reflected XSS

Attacker sends you a malicious link via email, doc, msg etc
You click on it (assume that in another tab you had already opened the same website and logged in, hence a session cookie is present)
The buggy website will reflect back the javascript payload in response that was embedded in the URL that was sent to you
Browser will execute the javascript, usually this javascript will be used to steal the session cookies.

Example for 1st payload:

Request(malicious link) :
http://buggy.com?data=%3c%69%6d%67%20%73%72%63%3d%60%78%78%3a%78%78%60%6f%6e%65%72%72%6f%72%3d%61%6c%65%72%74%28%31%29%3e

And server without doing any check on this input will reflect back the payload in response as:

<img src=`xx:xx`onerror=alert(1)>

This will make browser to create a pop up because xx:xx is an invalid
 source there by executing the script in onerror. In actual attack scenario you will have to replace alert(1) with the your javascript .

Example for 2nd payload:

Imagine the buggy website is fetching the value of lang parameter from the GET request and setting lang attribute of the html response without any checks.

Without payload:

Request: http://buggy.com?lang=en

Response:

lol

With the payload:

Request: http://buggy.com?lang=%22%3e%3c%69%6d%67%20%73%72%63%3d%22%31%22%20%74%69%74%6c%65%3d%22%74%72%75%65%22%20%78%3a%78%78%2f%6f%6e%65%72%72%6f%72%3d%22%61%6c%65%72%74%28%27%74%65%73%74%20%78%73%73%27%29%22%3e%20

Response:

 >

lol

This will make browser to create a pop up because :

1 is not a valid source again
forward slash in x:x/ is simply ignored or replaced with a space by the parser because img tag is a self closing tag
Inside a tag you can have a random string like x:x which will not have any effect on the browser nor it is against the syntax(i did not see any error being thrown in the browser console, someone can correct me i'm wrong)
In actual attack scenario you will have to replace alert('test xss') with the your javascript.


On password change in a web application, should it log out all other sessions?

TL;DR: How do you know it's not the attacker who is changing the password? In that case, you would log out the legitimate user. Or a user might want to routinely change their password (a good practice), but not if they have to login again on all devices every time. I would only log all other sessions out if (1) the user clicks the button "log all other sessions out", or (2) the user uses the forgot-password feature (thereby confirming their email address, or something else which provides stronger proof that it's them than a password).

When to log all other sessions out?

There are a few cases in which a user's password gets changed:

User notices or suspects a compromise, and changes their password
Attacker just gained access to an account and changes the user's password
User forgot their password
Attacker compromised user's email account and uses the forgot-password feature
User routinely changes their password, either because they think it improves security or because of a policy

In each case, you would want to make a different choice, but it's impossible to distinguish between the legitimate user and an attacker. Since you can hardly ask the user to confirm their password when using the forgot-password feature, we have to either disregard the case where an attacker compromised a user's email account, or use another method of confirming the user's identity (e.g. a recent purchase, an SMS verification code, a security question[1], etc.).

Since we do not know who is changing the password when it is changed from the interface, I think it's not unreasonable to leave other sessions active. In that case, other sessions should be terminated when a user does a password reset (after they confirmed the password reset link, not whenever anyone enters their email into the form, because that could be abused). Imagine the scenario in which both are logged in and know the password: both will try to change the password (assuming they know of each other) and it's just luck who gets there first. But once the password reset feature has been used successfully by someone, you have a higher confidence that this is the legitimate user.

Another consideration is whether to have a separate interface for logging other sessions out: you could have a button for "Log out all other sesssions", perhaps next to a list of all other sessions and past logins. I would recommend having this, since a user can check what is going on when something strange happens to their account. An attacker will be unable to hide their presence.

How to manage the sessions?

Ideally, you should have a list of active sessions for any account, as well as a history of logins. The history of logins should date back a certain amount of time, not a certain number of logins: if only the last X logins are shown, an attacker will be sure to look in the account history, spoof the user agent and country/state/city using VPN, and do X logins to push his own login out of memory.

This can be managed in a database, where each login session is registered. Using a expires column, you can purge sessions which have expired. And a session should get removed upon log out of course. Note that this is separate from login logging: having logged out, it should still be visible that someone logged into the account using <device> from <location> on <datetime>. The only thing to remove (or the boolean to toggle) is that the session is active.

Doing some trickery with bcrypt-hashed passwords, as described in the question, is not needed (and definitely not recommended!). The session state should be independent from a user's password by design: otherwise session tokens have a meaning which could be guessed if you make some tiny mistake, even if the attacker doesn't really know the password. Or conversely, an attacker could learn the password through offline brute-force, when all they ever obtained was a session token.

Generally speaking, there should be a list of sessions with at least two columns: session token and the user's unique identifier. The session token should be random bytes, optionally hashed (in order to not leak data from a compromised or weak PRNG). The user's unique identifier should be stable: no display name, and preferably not a username. Use a single-use unique identifier, such as an auto-incrementing column in MariaDB/MySQL. Usually a third column is added, expiration time, but this is not strictly necessary. I would highly recommend it, though, even if you set it to multiple years.

For each request, the database can be checked for the presence of the session token. If a user does something that invalidates other sessions, it's a simple matter to inactivate (or delete) the user's other sessions.

[1] Do not use security questions as a replacement for a password. The only reason I dare mention it, is because it can be an addition: when the user confirmed a secret code (or link) sent to their email account, or when they proved that they know their password, you could use it to get a little more certainty that it's the real user and not an attacker.


You're right, a single RSA key pair supports both signing and encryption; all restrictions are imposed by key flags configured during key creation time. Other public/private cryptography algorithms only allow one or the other action because of technical reasons (for example, DSA for signature and el-gamal for encryption).

The reasons in the linked Q&A apply also to OpenPGP. On one hand, you have key management advantages like individual key escrow. Generally, by "reusing" the same key, you might enable (known or yet unknown) attacks on the key that would not have been possible otherwise.

All in all, you have some benefits of using distinct keys for encryption and signature, at the same time OpenPGP takes all the hassles in maintaining multiple subkeys. The costs mostly boil down to some additional kilobytes added to your key and a negligible amount of computation time for creating the keys. Apart from running addkey twice, there is no additional administrative effort in creating a second key pair.

Considering there are some advantages (or at least might prevent possible attacks) for no costs, I do not see any reason not to create a second subkey pair.


Just by capturing the full traffic the task does not magically gets less complex. The traffic still needs to be processed and the information extracted. In contrary, capturing all traffic inside a huge network and processing it in real-time is a huge task: there is lots of bandwidth needed to collect all traffic in the first place and huge processing power needed to process it.
It scales much better to extract the relevant information as soon as possible from the network and only feed the pre-processed information into the SIEM. Apart from that SIEM usually not only get information from the network traffic, but also include information from the endpoints, like which applications are running and what they are doing, authentication errors etc. This is the kind of information which cannot be directly derived from the network traffic.


I believe you can find those defined in winnt.h.  (A sample winnt.h which seems to match correctly can be found included in the Wine project.)  The lower 16 bits are context-dependent (eg. they are interpreted differently depending on whether the handle is for a file, a threat, a process, etc.)

The bit patterns can be further described in MSDN.


How do I generate a blowfish password hash in Ubuntu?

bcrypt is based on blowfish. The difference between $2a$ and $2y$ is something else:

There are multiple implementations of bcrypt. And one of them, called crypt_blowfish, had a security related bug, drastically reducing the actual password space. Fixing this bug, however, caused existing bcrypt hashes to not match the passwords anymore. So this implementation started to use $2y$ to identify the fixed implementation, while still being able to maintain compatibility.

$2a$ of the original unix implementation and $2y$ of crypt_blowfish are identical.