You are not going to find a standardised metric because that's not how risk works. Figuring out how adverse events will have an impact is the whole point of risk management.

What would present a risk to a major university will be vastly different from what would present a risk to a 3-person app development start-up.

For instance:

  2.1 Anti virus installed everywhere?

For a small company that only uses Chromebooks, you can't install AV. And it doesn't matter.

For a university doing sensitive research, you could install AV on the research computers, but then the type of AV might send files to Russia, or the AV might interfere with the proper running of the analysis software. Installing AV would actually increase the risk instead of reducing it. The risk that is meant to mitigate is that malicious code could be run on a device. AV is just one control to mitigate this risk, and each control can present its own new set of risks.

I'm afraid that there are no shortcuts in risk. You need to understand the adverse events on your people, data, and technology and what impact they might have.

For broad strokes, there are frameworks that rank various controls against each other in general terms.

As alnbhclyn shared: CIS Top 20 Critical Security Controls has 3 broad categories of control maturity
Cyber Essentials presents a collection of controls in 5 broad categories that the NCSC feels are the most critical to mitigate 80% of the most common cyber risks

You might also look at the NIST CSF that breaks down 108 different activities into Identify, Protect, Detect, Respond, Recover, and you can score yourself on whether you are doing those activities and where you are weak. Be sure to go through each activity to determine how relevant they are to your organisation.


Data in L1 cache will not remain in L1 cache only; the hardware will copy it to main RAM transparently and almost immediately. At least so operate modern CPU. If you want to keep sensitive data out of RAM, then you must keep it in registers only. Context switches will be a problem, also, since they automatically flush registers to a designated RAM space.

While it is theoretically possible to operate only in registers and do encryption and decryption in the CPU only, it will be hard to do correctly (random-access encryption with updates is difficult to design without weaknesses) and it will be very expensive (you would more or less have to implement a virtual machine, where each opcode entails some decryption, so expect a slowdown of a factor 50 at least).

The TRESOR project appears to be much more limited in scope; it does not want to protect generic data from leaking to RAM, only encryption keys. Which, in my opinion, misses the point. You encrypt data because that data is sensitive and should be kept confidential. The encryption key is a high-value target because it concentrates secrecy, but certainly not the only target.


Client-side BCrypt, store salt and hash separately in MySQL database

The client is the attacker. Walk around your office while chanting that sentence 144 times; be sure to punctuate your diction with a small drum. That way, you will remember it.

In your server, you are sending Java code to run on the client. The honest client will run your code. Nobody forces the attacker to do so as well; and you use client authentication precisely because you fear that the client maybe be somebody else, who tries to impersonate the normal user. From your server point of view, you only see the bytes that you send to the client, and the bytes that come back. You cannot make sure that these bytes were computed with your code. The attacker, being an evil scoundrel, is perfectly able to envision not running your code and instead send the answer that your server expects.

Consider now a simple password authentication scheme where you simply store the users' passwords in your database. To authenticate, ask the user to send the password, and then compare it with what you stored. This is very simple. This is also very bad: it is called plaintext passwords. The problem is that any simple read-only glimpse at the database (be it a SQL injection attack, a stolen backup tape, a retrieved old harddisk from a dumpster...) will give the attacker all the passwords. To state things plainly, the mistake here is in storing in the database exactly the values that, when sent from the client, grant access.

And your proposed scheme ? Exact same thing. You store in the database the hash value "as is". And when the client sends that exact value, access is granted. Of course, the honest client will send the value by hashing a password. But, let's face it: many attackers are not honest people.

Now there is value in doing part of the hashing on the client side. Indeed, good password hashing is an arms race, in which the hashing is done expensive on purpose. Offloading some of the work on clients can be a nice thing. It does not work as well when clients are feeble, e.g. smartphones with Java, or, even worse, Javascript (which is a completely different thing, despite the name similarity).

In that case, you would need to run bcrypt on the client, and store on the server not the bcrypt output, but the hash of the bcrypt output with some reasonable hash function (a fast one like SHA-256 would be fine). The processing of a password P would then be a bcrypt on the client, then a SHA-256 of the result, computed on the server. This will push most of the CPU expense on the client, and will be as secure as a raw bcrypt for what it is meant to do (see below).

I understand that you want to "encrypt" passwords (hashing is not encryption !) because you want to use plain HTTP. You do not like HTTPS for the same reason as everybody else, which is the dreaded SSL certificate. Paying 20 bucks a year for a SSL certificate would be akin to having your skin removed with a potato-peeler sprinkled with lemon juice.

Unfortunately, there is no escaping the peeler. As others have remarked, even if you have a rock solid authentication mechanism, raw HTTP is still unprotected and an active attacker can simply wait for a user to authenticate, and hijack the connection from that point. A very common example of "active attacker" are people who simply run a fake WiFi access point -- that is, a completely real WiFi access point, but they also keep the option to hijack connections at any point. This is a kind of attack model that cannot be countered without a comprehensive cryptographic protocol that extends over all the data, not just an initial authentication method. About the simplest kind of such protocol is SSL/TLS. Any protocol that provides the same guarantees, that you absolutely need, will also be as complex as SSL/TLS, and much harder to implement because, contrary to SSL/TLS, it is not already implemented in the client software.

SSL is there, just use it. As for the lemon, suck it up.

(If the financial cost is a barrier, there are free alternatives, such as Let's Encrypt and pki.io. Whether they fit your bill remains to be seen, but they are worth considering if you are really short on cash.)


Is it possible for an attacker to change my sent emails content before arrival?

It is possible, but requires a relatively sophisticated attack.  E-mail is generally insecure.  Secure protocols do exist for exchanging e-mail, but very few servers actually use it.

If the attacker is able to execute what is known as a man in the middle attack, they could change anything they wanted about the e-mail.  A man in the middle attack requires that they have control over some part of the e-mail's route from sender to recipient.  This could be either the sending or receiving mail server, the user's e-mail client, or any Internet router that the e-mail happens to pass through along its way.

If the attacker can get in the middle, it is trivial to adjust, but it is relatively hard to get in to the middle unless they are a relatively established hacker with a decent amount of resources available to them.

In your case, the easiest countermeasure is the use of an HTTPS based link.  If you use SSL and the user bothers to check that the URL corresponds to your site, then the attack scenario doesn't work.  You could also tell them the domain that the link will go to when they choose to reset their password, that way they know if it is valid.  This is probably the easiest solution.


Picking an encryption algorithm for auth tokens passed via AJAX

Your use case is a bit strange. As a basic rule, you need SSL if the data you exchange between the server and the Ajax client is sensitive in any way; you need it both for confidentiality and for integrity. And if you have SSL, then you have all that you need; in particular, you defeat replay attacks (that's a feature of SSL).

You would have to fiddle with encryption only if you want to offload some of your storage on the client; that is, you maintain some user-specific state but do not want to pay for the corresponding database. Instead, you send that state to the client itself, to be stored either in a cookie or in the entrails of the RAM objects maintained by the Ajax code. In that specific scenario, the client is a potential attacker, and you want that storage to be protected with both encryption and integrity, and with an additional time stamp or counter. That's still a rather edge case and it is hard to get right; it is much easier to simply store the user state in the server's database.


Is it a good idea to use the entire Unicode range to generate a random password rather than limited ranges?

This sounds a lot like Fencepost Security.  Imagine you're running a facility that has chain-link fencing around it that is 500 feet high.  How much would the security improve by making that fencing 3,000 feet high?  None - because anyone trying to get in isn't going to climb the 500 feet; they're going to dig underneath, cut a hole, etc.

Likewise, you've got a password that's, say, 20 random alphanumeric characters.  That's 62^20 possibilities.  You're considering changing it to 20 random unicode characters.  Which raises the possibility space much higher, except brute-forcing a 20-character randomized password isn't how things are going to get compromised.


"Security through obscurity" is bad for security systems but good for spam detection. Why?

Security through obscurity is Always worse than an alternative which would be compliant with Kerckhoff's principal.

However, sometimes this is simply not possible. One good example of this is DRMs. With DRM, the content distributor wants to protect a content which he gives to the user. It is not possible in this case to rely on a secret key, because at some moment the user will also access this key to be able to use the content. Here the only solution is security bu obscurity. We can see though, that it never works so well. (Remember the DRMs on DVDs? it did not take long for them to be cracked...)

Your case, with spams, is similar. There is no way to implement a "secret key" scheme to detect spams... and therefore, the only remaining option is security through obscurity. Of course it is not excessively robust, but it is the best known solution as of today.


Can a program that doesn't explicitly take user input be hacked?

Short answer: Yes, DLL path highjacking.

Long answer: Though a program may not explicitly ask for user input, the operating system supplies resources for that program to run. So the attacker can target the program, the resources prepared for that program, or the interaction between that program and other necessary components.


Risks associated with compiling open source projects

Yes, the compiler, as any other program that executes code on your computer, can be used to add malicious instructions in a program, before or also after compiling it (e.g. ELF header and sections manipulation).


Best practice for two WebServices that have to authenticate with each other

You can use WS-Security to sign requests.  Depending on your application stack, you can even have a local CA sign the certificates, and use the CA signature to verify any of an arbitrary set of clients.


How to speed up brute forcing of finding a WEP key from a captured file?

You don't have enough IVs
Plain and simple. Cracking WEP works by statistical analysis, and in order to do that reliably, you will need lots of data.
The aircrack-ng FAQ says:

How many IVs are required to crack WEP?
WEP cracking is not an exact science. The number of required IVs depends on the WEP key length, and it also depends on your luck. Usually, 40-bit WEP (64 bit key) can be cracked with 300,000 IVs, and 104-bit WEP (128 bit key) can be cracked with 1,500,000 IVs; if you're out of luck you may need two million IVs, or more.

What does that mean?
Aircrack actually gave you the correct message. It said that with just barely over 1000 IVs, it can't deduct any information about the WEP key, so it'll try again once you have 5000 IVs, then again when you have 10000 IVs, and so on.
How can I successfully crack the key?
One thing you can do is to generate a lot of traffic. Tools such as aireplay-ng are designed to do just that.
The tool has a number of different attacks, some very specialized, some generally useful. For cracking WEP, the ARP Request Replay Attack and the Cafe Latte Attack are quite useful. Both attacks aim to generate more IVs.
Keep in mind you can have aircrack-ng, airodump-ng and aireplay-ng running all at the same time.


How to prove identity of my users from the public JSON files?

No, I am afraid it does not make sense. If you sign only parts of it, anybody can copy that sign Part  in his JSON.

It would be better to sign the whole JSON, by calculating a hash of it and then sign that. That way nobody can alter it without having to sign it again.


L2TP does not provide any confidentiality or authentication. A common setup is using L2TP along with IPSEC (see RFC 3193).

EDIT: L2TP does provide tunnel end-point authentication. It does not provide encryption and message authentication.


Which resources can help me learn how to use metasploit?

Yes, there is, it's called metasploit unleashed.

It is an official metasploit wiki with lots of information. It is structured kind of as a tutorial/course, and it gets upgraded and updated regularly. It is probably the best place to start.


Unfortunately unlike Word, Excel does not have a "Revision Tracking" feature.
However, there is an option in the home panel's info section, where you can see "Version History".  However, if the content in the document was copied and pasted into another document, then there would be no older version history to display.  That is one way one can circumvent the "Version History" feature.
This is the reason why it is standard practice for security personal at the work place to set up a database or a method to store hashes of files that they want to have a form of certain authentication.  Every time a known edit is saved a hash is saved in some manner (separate from where the document is saved), where an unknown edit would not change the hash of the previous version of the document.
Basically, if you have a hash for the document that was taken right after a known edit was saved, you could try comparing the current hash of the document with the known hash.  If the hash values are the same, then the document was never touched.  If it is not the same, then the document has been modified.


This is not a security risk.

The router looks in its ARP table to find the MAC address of your IP address. The reason it can do this, is because you are connected to the router via layer 2 in the OSI model. The router simply looks up your IP address in the ARP cache to find its MAC address. A website on the Internet is not connected to your LAN and will not be able to determine your MAC address.

In the same way, you from your computer determine the MAC address of your router by looking in the ARP cache of your computer. If you open up your command prompt (cmd.exe on Windows) and type "arp -a", you will see your router's MAC address. This does not pose a security risk, and is required for IP traffic to work on an Ethernet network.


Why attacker do not care about masking the IP of the infected device of botnet?

Infected devices are not owned by the attacker. So, it doesn't matter to the attacker if the bots are found.

Mirai was so successful that if a device was found, the attacker could simply get another.

Other botnets might be carefully controlled and tended by the attacker. They might be difficult or costly to maintain or to add new bots. In these cases, the attacker would want to protect it as much as feasible.


Samba printer usernames and passwords , security problem

I really don't feel this is a problem and I will explain you why.
If anybody got root access they could just sniff the traffic so every time anybody tries to authenticate the attacker can grab the hash of the password.

If anyone gets root access they can start arp spoffing DNS spoofing spoofing spoofing, which makes your network if compromised even more compromised.

If anyone gets root access they can log the keystrokes /events /everything going on

*nix users tend to have the most updated version of common sense

Somebody with system on an windows system got the same amount of access.

Worrying about someone reading a clear text password for an account with lover privileges, when they got root, is like worrying about a crack in the floor when the building is crumbling around you

What you should worry about is people getting root ;)

Stay safe


What is the difference between Compliance and Auditing in Information Security?

The way this was explained to me at a very basic level is the following:

Auditing refers to seeing who did what, when where, this could include systems and people. You'll probably hear the terms "audit logs" which refers to a series of logs that indicate who worked on a system, when and what they did.

Compliance refers to ticking (or not) a series of boxes after doing your audit. Think of compliance as the following question "Do my actions tick all the boxes?"
Eg. Is access to your customer data restricted to privileged users only?
You then do an "audit" (investigate the access logs) and if no unauthorised users can query the data, your are then compliant, hence you you pass some Compliance.

How do you link them together in a SIEM? Depending on what data you capture and the Compliance Standards you can simply query your data and then start ticking boxes to check the compliance.

This is a very basic explanation from a technical level. Compliance and auditing are slightly different when we are talking about legal, financial auditing and compliance.


PGP Key Signing Robot DKIM Verified Emails

DKIM only makes the promise that a specific mail server processed the mail. Only  DMARC creates is an association between the From header in the mail and the DKIM signature. But this association is restricted only to the domain part of the address, or even only the organizational domain depending on the restrictions in the DMARC record.

There is no proof that the mail address set in From-header of the mail is actually used in the MAIL FROM part of the SMTP dialog. I.e. it might be that the first is trusted@example.com while the second is attacker@example.com. Because the domain part of the From address still fits the DKIM signature everything looks fine.

It might be that the mail server will make sure that the sender given in the SMTP dialog and the From header will be the same. But I can find nothing about this in DKIM or DMARC specification. And while gmail and yahoo seem to rewrite From if it does not match the SMTP envelope there is no guarantee that others will do it too. This means, that you cannot use a DKIM signature to validate an E-mail address as long as you don't know how this case is handled by a specific mail provider now and also in the future.


This would also allow for symbols and spaces... blacklisting certain
  words and symbols...

What you are talking about? What blacklisting? From the security point of view passwords can contain anything you want. To prevent SQL injection any reasonable application uses prepared statements: Java, C#, PHP. In your case it will generate following SQL, which return no result (unless you really have such a strange user name):

"SELECT * FROM users WHERE username = ''' OR 1=1;--'"

Blacklisting of some symbols is done for better usability, not for security. How would user count spaces, how will he distinguish if there are 2 or 3 spaces in a sequence? How would user enter TAB symbol?

Blacklisting of some passwords like "123" or "abc" is done to prevent guessing them, to prevent dictionary attacks.


Can I connect our network to the internet but only allow connections to certain servers?

Limiting access to certain addresses

A firewall that connects your network to the Internet can do exactly this. You whitelist the IPs that you want, and default deny any other communications (in or out). I don't normally suggest going to a custom firewall (Linux OS on a computer that only does firewall and is used for nothing else) right away, but I think it may give you the simplicity and power that you need. The upside is that you might be able to use equipment you already have for this purpose, considering the throughput you suggest (providing it is not too old).

pfsense is highly regarded.

That said, you will have to write the firewall rules. So, it is not 'point-and-click', and requires a moderate level of skill, but totally doable.

Spoofing Windows Update

It is possible to spoof a software update site, but programs such as Windows Update and Symantec update verify the address it is connecting to, so the risk is very low.

EDIT

Oh, and I'm sure someone will point out, so I'll beat them to the punch: you are likely exposing your network to more security issues by allowing USB keys and personal electronics in your network than with a poorly configured firewall (given the right conditions). So, by limiting (eliminating) those things and having a good firewall, you will be miles ahead than where you are now.


How is a pepper used with salted passwords?

Salt is a random string that is used to mitigate dictionary attacks.

+-------+------------+-----------------------+
|  id   |    salt    |       hashed_pw       |
+-------+------------+-----------------------+
| user1 | 9060d63fe0 | hash(pass19060d63fe0) |
| user2 | 39b3cdd660 | hash(pass239b3cdd660) |
+-------+------------+-----------------------+

Pepper is a fixed string that is more secret then the salt, and this mitigates brute force attacks on salted passwords.

  Is a pepper simply concatenated to the beginning or end of a salted password? Is it concatenated to the salted password, which is then hashed again?

Peppers should not simply be concatenated because it's goal is to make brute forcing impossible. It too must be hashed.

Let's assume password abcd1234 and salt 9060d63fe0. If those two are hashed with bcrypt with round 9, the result will be $2a$09$T.FYSHNRG5W.EiS3ieAU/OqdnNLXtou3yZk98/ZJ0Y7JXAoFlVWKS.

If somehow hacker brute forces the password and manages to find the value abcd12349060d63fe0, the hacker will know that the salt value is 9060d63fe0 and the password is abcd1234 because salt is stored on the DB.

But let's assume a pepper is applied. pepper abab4321, password abcd1234 and salt 9060d63fe0. If hacker successfully brute forces
 and found abab4321abcd12349060d63fe0, the hacker won't be able to know which part is the pepper and which is the password.

Peppers can be applied before hashing like this:

+-------+------------+-----------------------------+
|  id   |    salt    |          hashed_pw          |
+-------+------------+-----------------------------+
| user1 | 9060d63fe0 | hash(pepperpass19060d63fe0) |
| user2 | 39b3cdd660 | hash(pepperpass239b3cdd660) |
+-------+------------+-----------------------------+

Or after hashing like this

+-------+------------+--------------------------------------+
|  id   |    salt    |              hashed_pw               |
+-------+------------+--------------------------------------+
| user1 | 9060d63fe0 | hash(pepper + hash(pass19060d63fe0)) |
| user2 | 39b3cdd660 | hash(pepper + hash(pass239b3cdd660)) |
+-------+------------+--------------------------------------+


How to effectively (and reasonably) secure Windows in corporate environment.

Follow a proven hardening standard like NIST for example:
http://csrc.nist.gov/itsec/SP800-68r1.pdf

Implement user awareness security training.  http://www.sans.org/reading_room/whitepapers/awareness/importance-security-awareness-training_33013

Upgrade OS and applications. Although supported until 2014, it is unlikely that there will be another major service pack and several vulnerabilities currently exist that will likely go unpatched.


How should I detect and respond to bad actors who perform SQL injections?

The right way to act is to reject the request (fail request before starting any application code / SQL queries) and log the event with complete debugging information into the database, assign number to it and output the number to screen.

This should be not the same database as the operational one, it should be service database where you normally store logs of operations.

If it's API call, then make this number appear in the error message box.
This is to deal with false positives for once, and secondly to deal with the successful attempts of injections.

However you cannot prevent "select 1;" arguments from being passed every time  because it's always possible to pass "select 1;" somewhere and such request should be blocked before reaching the application code.
Also, this is best implemented on dedicated "layer" where request is decoded and checked for this kind of stuff like mod_security does.

There's no way to block the user and log him out because there will be far too big impact, it's also on the wrong layer - it's application code layer and not the dedicated security layer.


Accidentally clicked a phishing link, am I at risk?

You likely have nothing to worry about. Phishing relies on tricking you into entering sensitive credentials. It's very rare for it to exploit you directly and if they did want to do that, they wouldn't be showing you a password prompt. However, it is possible that merely typing in your account details sent data to them even if you did not press enter, so you should change your password. I don't think that's likely in this case, since I logged network activity while typing a dummy password into that phishing site and could only see it send it when I actually pressed enter, but it's still a good idea to change those passwords.

It is possible that the page has attempted to use exploits against your browser regardless. Generally, these exploits will be against old browsers or outdated plugins. If you keep your browser up to date, it should not have public security issues that could be used to install malware via a drive-by download.


Functions in common server-side languages which are used to execute code

Minor ranting

This is a bit broad, and there may be some that are unknown at present, but there's usually good references out there if you're willing to search for them.

Code execution isn't the only problem. You want to be careful of things that can lead to code execution.

However, and as always, it's important to study these functions to see what they're capable of, rather than just blanket-rejecting them as a vulnerability - especially when there are often legitimate uses for them.

As a penetration tester, your job is to prove there is a vulnerability by creating a Proof of Concept, unless it's glaringly obvious, such as a SQL injection.

Give me the list of all of them!

You want to list all of them? Well, I'm not sure we have such a list... but how about many of them?

PHP - Exploitable PHP Functions
Java - Exploitable Java Functions
Python - Exploitable Python Functions
Ruby on Rails Cheat Sheet


If I use a VPN such as IP Vanish on my office network, can they see

Nothing is really safe, and from the sound of it, you're using a system that you don't control, to access systems the network administrator or management is trying to prevent access to. It's not in their best interest for any of these types of connections.

That being said, outside of any legal concerns that might develop (intellectual property transmission, etc) if it's your personal machine that you're using with VPN then you should have an encrypted channel to the IPVanish servers. That being said, since you don't control the network, you could be victim of a MITM attack if your company wanted to decrypt your traffic. There are systems such as SSL off-loaders that could be used and if you access the system via special access point or through a corporate proxy, then you could have other issues in regard to decryption. Additionally you'll want to watch out for DNS requests going through non-encrypted channels. If this is the case your company can see where you're going, they can't see what you're saying or sending.

If you're using a company computer, depending on the local laws they may be able to track everything you're doing via the use of keyloggers and snapshots of the system depending on what system is running, and whether they allow remote access and monitoring on that system.

If corporate policy is not to do this, then you're likely in violation of that policy. At any rate they will be able to see that you're connecting to a VPN over the corporate network's firewall (if they have IT who are savvy enough). Additionally they will likely feel any bandwidth the VPN connection is using, as all of your traffic will require more bits to transfer depending on the encryption level.


Is it proper to be informed that I entered an old password

Is is fairly common to keep a password history in an authentication system. Remember, they are storing hashes/representations of your password, not your actual password and are comparing against those, so there is not a lot of risk of exposure or social engineering here. I guess there is a small risk here, that if an attacker is intercepting your network traffic and is MiTM (even on SSL) he will see your password and now its an old one, and can assume you are using the password on other sites. However, if your traffic is already being intercepted they will see the new password as well, and probably all of you other traffic.
The prompt saying when you changed the password does not pose a real security risk. This is so that way you determine if the last password change was performed by you, if you don't remember changing your password at that time, you should make sure to change it now and figure out how you were compromised. As for the local network or computer, its probably just using your public IP address; if you are behind a home router (using NAT) all of your computers will appear to the Internet as the same IP. I am actually surprised it doesn't tell you your password was changed from another PC or network, I've seen Google warn me about attempted logins from IPs in other countries.

I am not sure where the social engineering issue is in this scenario - are you being asked questions like "What high school did you go to?" as a challenge question (e.g., something public or part of your Facebook profile?).


Is it possible to bypass sniffing when using port mirroring?

Yes, but under very limited circumstances.

Under heavy loads SPAN ports are known to drop packets. Forced to make a choice between continuing to route/switch traffic or mirroring it to a second interface, the former will always take precedence.

It is entirely possible that a PCAP will not contain all the mirrored traffic you expect, but it is unlikely a user could deliberately bypass it unless they also flooded the device.

This is pretty much the use case we have for monitoring mainframe traffic. SPAN ports are not 100% reliable. Do not use mirroring if you need incontrovertible evidence of network activity. Buy a tap.


Difference between socks5 and socks4 proxy?

From wikipedia:

  The SOCKS5 protocol is defined in RFC 1928. It is an extension of the SOCKS4 protocol; it offers more choices for authentication and adds support for IPv6 and UDP, the latter of which can be used for DNS lookups.

And compared to plain SOCKS4 it also has the main feature from SOCKS4a:

  SOCKS4a extends the SOCKS4 protocol to allow a client to specify a destination domain name rather than an IP address; this is useful when the client itself cannot resolve the destination host's domain name to an IP address.


I just send username and password over https. Is this ok?

This is fine.  You don't need to do anything else.  There is no need to hash it or obfuscate it in RAM.

You should be careful to hash the password appropriately on the server side before storing it in persistent memory (e.g., in a database), and you should take care to use proper methods for password hashing.  See, e.g., How to securely hash passwords?, Which password hashing method should I use?, Most secure password hash algorithm(s)?, Do any security experts recommend bcrypt for password storage?.

If you want to provide additional security for your users, here are some steps you could take:

Use site-wide SSL/TLS.  Any attempt to visit your site through HTTP should immediately redirect to HTTPS.
Enable HSTS on your site.  This tells browsers to only connect to you via HTTPS. Paypal uses it.  It is supported in recent versions of Firefox and Chrome.

I'm not saying you need to do these things (though site-wide SSL/TLS makes a big difference).  But these are some options that can help strengthen security against some common attack vectors.


Can wildcard certificates hide/obscure the hostname in a TLS connection?

You'll still see server names in client hello SNI extensions.


What are the guarantees that TLS provides without using a certificate in the scenario?

Yes

If the server doesn't present a certificate (or it is not validate), the client will happily give {Token, Request} to the presumed server. A MITM could act as the server, receive the tokens and requests and pass them to the real server.

They do not need to be signed by a public CA, though. You could be using your own PKI (a private CA to sign those certificates) if that makes your life easier.


Is it possible to create a SMIME only PKI that *can't* be used for SSL?

It is possible to create a root CA that cannot be used for SSL by... not using it for SSL !

When a CA issues a certificate for a sub-CA, it does so within the context of a given trust contract. The sub-CA agrees to issues certificates only in accordance to a number of rules which are made explicit in the Certification Policy and the Certificate Practice Statement -- these are legal documents meant for human consumption. If you want a root CA which can be used for S/MIME but not for SSL, then the root CA must state in its CP and CPS that certificates which relate to this root CA must not be used for SSL. In particular, sub-CA take the formal oath never to issue SSL-able certificates (i.e. they won't put machine names in Subject Alt Name extension or in the Common Name part of the SubjectDN; and they will put a critical Extended Key Usage extension which says "for S/MIME only").

In X.509, there are two categories of such "PKI rules":

Rules which are enforced by the validation algorithm. Name Constraints, for instance, can (theoretically) be used to prevent validation of certificates such that the end-entity certificate's name is not part of a namespace of allowed names duly specified in one of the intermediate CA certificates.
Rules which are not enforced by the validation algorithm. The "no SSL" rule would be such a rule.

In pure X.509 theory, there is no actual need for rule enforcement in the validation algorithm; revocation is used to maintain order and punish misbehaving entities. However, in practice, revocation is asynchronous, and too slow to react to "flash attacks". An attacker who wants to run a fake server only needs ten minutes or so  to enact considerable mischief; seeing his certificate revoked two days later won't deter him. This is why a number of PKI rules are now enforced at the validation level, first of which being incarnated by the Basic Constraints extension: a certificate owner is not granted CA power.

There is (currently) no such automatic enforcement of rules pertaining to Extended Key Usage. If a CA wants to enforce a no-SSL rule, then it must not issue certificates which can be used for SSL, and it must make sub-CA swear to comply to the same rule. Lack of such enforcement is a problem only if a sub-CA misbehaves, and the obtained certificate can be used as a SSL server certificate to perpetrate some odious crime before righteous revocation smites the offending sub-CA.

(Note that the Key Usage extension only covers a handful of generic use cases, such as "encryption" or "signature", and this is unrelated to Extended Key Usage. Moreover, the Key Usage extension is no more inherited along a certificate path than the Extended Key Usage extension.)

There is another point where rules can be engraved: in the clients. Clients trust root CA (that's what makes them "root CA"), but they can trust them for specific roles only. See for instance this screenshot from the certificate viewer in Firefox's preferences:

The list of "uses" is configurable and allows the client to restrict a given CA to some specific situations.

This mechanism:

is not backed by information written in the root CA certificate itself, but by metadata which must be maintained by some out-of-band mechanism;
is not standardized (every system has its own notion of "roles");
is specific to root CA (trust anchors) and cannot be attached to an intermediate CA;
is worth anything only insofar as the relevant applications mind the restrictions and enforce them.

Yet it works. If you want an S/MIME-only root CA, then distribute it and have it installed in clients with the tag "for S/MIME only". This is as good as a full-path automatic EKU extension (if such a thing existed).


Trying to examine URL redirection in Wireshark

A TCP handshake does not contain any redirect information. If you check instead at the application layer you see:

$ curl -v http://indistannews.com/
...
< HTTP/1.1 301 Moved Permanently
...
< Location: http://sexiniowa.info

Since this is a 301 permanent redirect the client does not even need to visit the original site again but will instead use the new location on repeated tries. Only on the first try it will visit the original site to receive the redirect. And this is what your packet capture might show.


When Shellshock was introduced, how bad was it **then**?

How bad?  Not very.

None of the common remote attack vectors existed when the bug was introduced: the "shellshock" parsing bug pre-dates CGI and DHCP by about a year, and pre-dates SSH by two to three years.  Remote-access programs such as telnet and rsh don't have the command restriction ability that SSH does, so although a "shellshock" attack could probably be mounted against them, it wouldn't gain an attacker anything they couldn't get just by logging in normally.

As for local privilege-escalation attacks, as far as I can tell, Linux has never supported setuid scripts.  There aren't very many setuid programs: at the time, they would have been what are now the "util-linux" and "shadow" packages.  These programs are part of the POSIX specification, and haven't changed in their fundamental operation in the past 20 years.  Of them, only su, mount, and umount are setuid and call other programs, and all of them do it through exec*().  su did and still does pass the environment through if invoked without -, but it's not an easy attack vector to use: you need to get your target to execute it with an environment under your control, and invoking it as su - (which cleans the environment) is second nature to many sysadmins.

The big wildcard is other *nix-like systems.  The GNU userland was a popular replacement for low-quality vendor programs, and some of the *nix-like OSs supported setuid scripts.


Your title asks about storing data. The body of your question asks about transmitting data. The purpose of a one time password is to only use a password once. They do not need to be protected, but that's assuming the network is safe which is a matter of cryptographic authentication or a matter of trust in the network.

Entering secret data defeats the purpose of one time passwords. Since pins are so short you could reverse the encryption by brute force. Your description is so vague, I am certain there are be various other problems in the scheme as you understand it.

I beleive Wikipedia has multiple concise articles about different one time password algorithms.


Is using the 2FA secret on the same machine as using the credentials, removing one factor of 2FA?

Yes. Concept of two factors is to authenticate using any combination of the below methods

Something you know (password)
Something you have (OTP token with secret)
Something you are - Fingerprint, retina , palm scan etc...

If you hide both of them under third password (or even without password), you are weakening the whole concept. If the attacker can get through this single password, he got complete access (that would not happened with proper 2FA).

But people are lazy and therefore these plugins exists. The need to use 2FA might be also triggered by some security policy and the users might not see the benefit of it.


Phishing is a way to collect your private information, usually site username/password, but also sometimes your CC info.

Did you type any of this on the page that you were send to from Facebook?

If not - it's not phishing.

It can be "click jacking"
or, most likely, they tried to install something on your computer.

From their site an attacker can't access SessionID/cookie of other sites (unless it has some vulnerability)


Can the attacker view the response from a CSRF attack request?

Is there any way such that the attacker can view the response generated when the victim clicks on the button?

No, not in a pure CSRF attack. The direct effect of a CSRF attack is not information disclosure. It is tricking the server to perform some action. Examples of CSRF attacks would be:

Delete a post by directing a CSRF attack at example.com/posts/delete.php.
Changing the victims email to the attackers by tricking the victims browser to send a POST request to example.com/user/update.php.
And so on...

The thing here is that the attacker doesn't need to read the response. As long as the server deletes the post or changes the email or whatever the attacker wins. A side effect of that could be some kind of information disclosure, but that is not the primary effect.

On a side note, the attacker doesn't have to trick the victim into clicking a button on the attackers page. All she has to do is trick the victim into visiting the page, the rest can be done automatically in the background with javascript.


Can the GPG master secret key be stored as read-only?

Keys don't store data, they encrypt data.  The data that it encrypts will change, but the key itself can't change or you would be unable to access your previously encrypted key-rings.

Now, you can role things forward to a new key by decrypting your entire key-ring and re-encrypting with a new private key, but that would only be done if your key became compromised (at which point you should really replace all your keys on your ring as well.)


Cannot understand supposed ProtonMail vulnerability from wired.com article

This is mostly a guess on what they mean:

Well, Public key schemes need the trusted third party. In this case ProtonMail is assumed to be the third party, who - the first time Alice and Bob communicate - give Alice a public key owned by themselves. When Alice then send mails to Bob ProtonMail decrypts the mail and encrypts it with Bob's key, but keeps the unencrypted mail for themselves.
So as the article states:

  ProtonMail does allow you to export your public key and send it to another person, but you can’t easily confirm whether your ProtonMail messages are being sent to the same key. It would take serious tech chops to verify the key.

You could send the public key to the recipient beforehand, but they then must trust that it is you sending it.


ms08_067_netapi not performing as expected on Windows XP SP1/SP3

There are many reasons for this exploit to fail, in short:

The target is patched.
'Not supported language' error from the target.
The payload can't execute correctly.
Networking errors 'reverse connection through NAT'.

From experience with the same issue, I recommend to do the following:

Try not to use VMs.
Try another payloads, away from reverse connections.
Try other versions of Windows XP.
Change system languages 'sometime it works!'

After all, since it says Exploit completed, but no session was created that means something is preventing the reverse connection, mostly the system is patched.


Security of re-encryption with a list of pre-computed password based keys

If I understand your problem correctly, what you want is that, for a given file:

A file is stored on an untrusted server.
There is an ordered list of passwords which are "attached" to the file (but bit stored with the file).
When at rest, the file shall be encrypted with the first password of the list (that is, encrypted with a key that can be recomputed from the knowledge of the password).
When the password is submitted to the server, the server decrypts the file with it, does "something" with the decrypted data (e.g. returns it to the user), and reencrypts the file with the next password in the list.
The server has no permanent knowledge of the passwords themselves.

This implies that there are moments when the server "sees" the decrypted data, so the server must not be totally untrusted. I assume that we are interested in protecting the data at rest (scenario: the attacker steals a backup tape for the server, and thus has read access to the stored files, but not to the server RAM). I am not studying active attacks here; if the attacker can modify the server data, then you have bigger problems. Another important point is that what the server contains is necessarily vulnerable to dictionary attacks (knowledge of what the server knows, plus the current password, is sufficient to recover the data) so the passwords must be strong (high entropy, bcrypt...).

The characteristics above imply that the server must be able to encrypt data relatively to a password that it does not know, so this calls for asymmetric cryptography. What you suggest is functionally equivalent to storing with the file a sequence of password-protected private keys, along with their public keys: the password, when provided, unlocks the private key, which is used for the decryption, and the immediate reencryption uses the next public key in the list. Your gHn is just a private key password protection: the private key is the (hash of the) password, and the stored value is the public key.

If you want to stick to well-studied standards (which is wise !), consider OpenPGP. It includes formats for storage of public keys, password-protected private keys, and bulk data encryption. It is supported by existing libraries (e.g. GnuPG or Bouncy Castle).

A streamlined format could be defined along the lines that you thought of (possibly with elliptic curves, to reduce the size of the list of keys), but it would be a rather large endeavour with many things which can go wrong (the password hashing, the symmetric encryption, the details of Diffe-Hellman, a possible indirection to speed up the reencryption step... all add to the complexity).


Can my school see exactly what I’m doing?

You are not giving enough context.  If they are just requiring that you have the default digicert global root certificate (that is pre-installed on most operating systems and web browsers), that isn't a problem.

That said, some network environments (typically workplaces with strict network policy) monitor network usage by using a man-in-the-middle attack on all HTTPS connections.  You can test this by seeing if the HTTPS certificates fingerprints match well known ones.

E.g., visit https://www.grc.com/fingerprints.htm on your phone and then visit a domain, and check that the SHA1 fingerprints match.  (In most browsers you can find the certificate information by clicking on the lock part of the URL and going through the menu to get certificate information).

Please note they can always observe which IP connections you are sending data with, all HTTP (not HTTPS) you are visiting, the server name (www.example.com) of HTTPS sites you visit (the server name identification standard allows this to be sent in plaintext).

For example, typical ubuntu installations come with DigiCert_Global_Root_CA.pem being trusted:

$ cat /etc/ssl/certs/DigiCert_Global_Root_CA.pem
-----BEGIN CERTIFICATE-----
MIIDrzCCApegAwIBAgIQCDvgVpBCRrGhdWrJWZHHSjANBgkqhkiG9w0BAQUFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD
QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGExCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xIDAeBgNVBAMTF0RpZ2lDZXJ0IEdsb2JhbCBSb290IENBMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1eqUKKPC3eQyaKl7hLOllsB
CSDMAZOnTjC3U/dDxGkAV53ijSLdhwZAAIEJzs4bg7/fzTtxRuLWZscFs3YnFo97
nh6Vfe63SKMI2tavegw5BmV/Sl0fvBf4q77uKNd0f3p4mVmFaG5cIzJLv07A6Fpt
43C/dxC//AH2hdmoRBBYMql1GNXRor5H4idq9Joz+EkIYIvUX7Q6hL+hqkpMfT7P
T19sdl6gSzeRntwi5m3OFBqOasv+zbMUZBfHWymeMr/y7vrTC0LUq7dBMtoM1O/4
gdW7jVg/tRvoSSiicNoxBN33shbyTApOB6jtSj1etX+jkMOvJwIDAQABo2MwYTAO
BgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUA95QNVbR
TLtm8KPiGxvDl7I90VUwHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUw
DQYJKoZIhvcNAQEFBQADggEBAMucN6pIExIK+t1EnE9SsPTfrgT1eXkIoyQY/Esr
hMAtudXH/vTBH1jLuG2cenTnmCmrEbXjcKChzUyImZOMkXDiqw8cvpOp/2PV5Adg
06O/nVsJ8dWO41P0jmP6P6fbtGbfYmbW0W5BjfIttep3Sp+dWOIrWcBAI+0tKIJF
PnlUkiaY4IBIqDfv8NZ5YBberOgOzW6sRBc4L0na4UU+Krk2U886UAb3LujEV0ls
YSEY1QSteDwsOoBrp+uvFRTp2InBuThs4pFsiv9kuXclVzDAGySj4dzp30d8tbQk
CAUw7C29C79Fv1C5qfPrmAESrciIxpg0X40KPMbp1ZWVbd4=
-----END CERTIFICATE-----

which contains the information:

$ openssl x509 -text -in /etc/ssl/certs/DigiCert_Global_Root_CA.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            08:3b:e0:56:90:42:46:b1:a1:75:6a:c9:59:91:c7:4a
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
        Validity
            Not Before: Nov 10 00:00:00 2006 GMT
            Not After : Nov 10 00:00:00 2031 GMT
        Subject: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:e2:3b:e1:11:72:de:a8:a4:d3:a3:57:aa:50:a2:
                    8f:0b:77:90:c9:a2:a5:ee:12:ce:96:5b:01:09:20:
                    cc:01:93:a7:4e:30:b7:53:f7:43:c4:69:00:57:9d:
                    e2:8d:22:dd:87:06:40:00:81:09:ce:ce:1b:83:bf:
                    df:cd:3b:71:46:e2:d6:66:c7:05:b3:76:27:16:8f:
                    7b:9e:1e:95:7d:ee:b7:48:a3:08:da:d6:af:7a:0c:
                    39:06:65:7f:4a:5d:1f:bc:17:f8:ab:be:ee:28:d7:
                    74:7f:7a:78:99:59:85:68:6e:5c:23:32:4b:bf:4e:
                    c0:e8:5a:6d:e3:70:bf:77:10:bf:fc:01:f6:85:d9:
                    a8:44:10:58:32:a9:75:18:d5:d1:a2:be:47:e2:27:
                    6a:f4:9a:33:f8:49:08:60:8b:d4:5f:b4:3a:84:bf:
                    a1:aa:4a:4c:7d:3e:cf:4f:5f:6c:76:5e:a0:4b:37:
                    91:9e:dc:22:e6:6d:ce:14:1a:8e:6a:cb:fe:cd:b3:
                    14:64:17:c7:5b:29:9e:32:bf:f2:ee:fa:d3:0b:42:
                    d4:ab:b7:41:32:da:0c:d4:ef:f8:81:d5:bb:8d:58:
                    3f:b5:1b:e8:49:28:a2:70:da:31:04:dd:f7:b2:16:
                    f2:4c:0a:4e:07:a8:ed:4a:3d:5e:b5:7f:a3:90:c3:
                    af:27
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55
            X509v3 Authority Key Identifier:
                keyid:03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55

    Signature Algorithm: sha1WithRSAEncryption
         cb:9c:37:aa:48:13:12:0a:fa:dd:44:9c:4f:52:b0:f4:df:ae:
         04:f5:79:79:08:a3:24:18:fc:4b:2b:84:c0:2d:b9:d5:c7:fe:
         f4:c1:1f:58:cb:b8:6d:9c:7a:74:e7:98:29:ab:11:b5:e3:70:
         a0:a1:cd:4c:88:99:93:8c:91:70:e2:ab:0f:1c:be:93:a9:ff:
         63:d5:e4:07:60:d3:a3:bf:9d:5b:09:f1:d5:8e:e3:53:f4:8e:
         63:fa:3f:a7:db:b4:66:df:62:66:d6:d1:6e:41:8d:f2:2d:b5:
         ea:77:4a:9f:9d:58:e2:2b:59:c0:40:23:ed:2d:28:82:45:3e:
         79:54:92:26:98:e0:80:48:a8:37:ef:f0:d6:79:60:16:de:ac:
         e8:0e:cd:6e:ac:44:17:38:2f:49:da:e1:45:3e:2a:b9:36:53:
         cf:3a:50:06:f7:2e:e8:c4:57:49:6c:61:21:18:d5:04:ad:78:
         3c:2c:3a:80:6b:a7:eb:af:15:14:e9:d8:89:c1:b9:38:6c:e2:
         91:6c:8a:ff:64:b9:77:25:57:30:c0:1b:24:a3:e1:dc:e9:df:
         47:7c:b5:b4:24:08:05:30:ec:2d:bd:0b:bf:45:bf:50:b9:a9:
         f3:eb:98:01:12:ad:c8:88:c6:98:34:5f:8d:0a:3c:c6:e9:d5:
         95:95:6d:de

There should be no problem if they require you to have this certificate installed; e.g., Mozilla trusts it by default.  It would be a problem if they require you to install and trust a different certificate by the same name.  That said I am unfamiliar with the certificate going by the name "digicert sha2 secure server".  Is the fingerprint of that certificate listed in the certificates trusted by Mozilla?


Password resets - what practices should web services follow?

I've actually been working on some ideas around this area, so here's a dump of my thoughts so far. I apologise in advance for the ridiculous length of this answer.

Password reset mechanisms have to be designed with three major goals in mind:

Security
Usability
Reliability

For a good mechanism, we need to reach a balance between the three.

A few assertions that I'd like to make before starting:

You cannot rely on users' computers to be secure.
Security through obscurity is not security.
Crypto is hard. Don't roll your own.

Right, on to the actual answer!

1. Multi-factor authentication

Multi-factor authentication (MFA) is one of the most secure methods for account recovery, and human authentication in general. For those of you that are unfamiliar with MFA, it works on the principle that you must have more than one credential in order to authenticate:

Something you know (e.g. password, secret answer)
Something you have (e.g. key, hardware token, etc)
Something you are (e.g. fingerprint)

Note that having multiple of one type, e.g. two passwords, or a password and a pin, does not count as MFA. I'm looking at you, online banking sites.

1.1. Something you know

When resetting a password, a common way to authenticate the user is to ask them some questions. Unfortunately, these questions are usually things like "What school did you go to?" and "What's your mother's maiden name?", which are incredibly easy for attackers to find out through social networking. Furthermore, many users dislike answering these questions when signing up, so they just hit a bunch of keys and invalidate the purpose of the question.

For e-commerce webapps, and other webapps that store private personal information (e.g. address / phone number), one might ask for that information. However, keep in mind that this information might be found online too.

An alternative would be to ask contextual questions, based on the user's experience on the site. For example, Hotmail asks for an email address that you have recently communicated with, as well as some other information about activity on your account. This is quite adaptable across most types of webapp, but isn't always applicable.

1.2. Something you have

Often sites will describe emailing a link or one-time password to your email address as a form of MFA. I assert that this is a false assumption. Users share passwords between accounts. This is an absolute fact, and you cannot prevent it. As such, you must assume that an attacker already has access to the user's email address. We'll cover the implications of this later.

The proliferation of cellphones has made them a great mechanism for two-factor authentication, as a form of out-of-band check. SMS reset tokens are easy for the user to understand and use, and an attacker having access to the phone is unlikely. However, this method is not without flaws. The biggest problem is when a user loses their phone, or changes provider. This completely invalidates the phone as a usable reset device. Another problem is that users don't always have their phone with them.

Using an app on smartphones partially fixes this problem. If a user changes their provider, the app remains on the phone. Allowing both SMS-based and app-based resets allows for a reasonable expectation of reliability.

Alternatively, allow the user to associate a login provider account (e.g. OpenID) and use a valid logon for that account as a "something you know" proof.

Other potential mechanisms:

Physical token (e.g. RSA SecurID, USB token) - not exactly viable for most places, but useful for banks, internal corporate systems and other high-security situations.
File - Randomly generated file given to the user on signup. Hash stored in database. Upon reset, user asked to provide file. Not the best usability or security, but potentially useful.

1.3. Something you are

This is where things get fun and sci-fi. Biometric authentication is something that has become more popular recently. Quite a few laptops include fingerprint scanners, and you can pick up cheap USB ones for a relatively small cost. Another popular biometric mechanism is facial recognition, via webcam. Both of these are excellent in terms of security when done right, but they both have a few problems:

Most implementations are probabilistic, and therefore insecure. What stops an attacker from holding a photo of your face up to the camera?
You can't rely on every user having a fingerprint scanner, and those that do aren't all compatible with each other. Furthermore, you're interfacing with hardware, so that requires a native app to talk to your webapp.
The field of biometrics is relatively new, so there aren't any well-aged properly-studied implementations with fully understood security models.

All in all, the "something you are" model works for in-person identification, but isn't really feasible for webapps unless you're providing your customers with fingerprint scanners and appropriate software.

1.4. MFA best practices

Single-factor authentication is not enough. As we've seen from all the recent breaches it's difficult to keep passwords secure, and even when they're hashed they can still be broken. MFA is necessary for both login and password recovery. Mobile authentication for recovery purposes solves most problems, as long as the mobile device is still usable. In the case of mobile authentication not being possible, you must have a manual verification process in place, where they have to convince a human that they are the real deal.

2. Reset mechanisms

There are a multitude of different password reset methods out there, many of which fall way behind in terms of security. I'm going to discuss some that I've seen in the wild, explain their good and bad points, and propose some better ones.

2.1. Emailing the password back

The most basic mechanism is to just email the user's password to them. Please don't ever do this. It's horrible beyond measure. First, it requires that you're storing passwords in cleartext, or at least in a reversible format. You must hash passwords properly, and follow best practices for salting. Second, you're emailing the user's password in cleartext, over a cleartext protocol, over the internet. There's a special level of hell reserved for people who do this.

2.2. Generating a new password

Some sites generate a new random password, hash it, then email it off to the user. This isn't a good idea for quite a few reasons, though most of them can be mitigated in some way. The most fundamental issue is that you're emailing a usable password to a user in plaintext. Other issues with this method include:

Many users are lazy, quite a few will reset and just tell the browser to remember the random password.
A lot of sites don't force you to change the password upon first use of the password.
An attacker having access to the email account has access to the password, regardless of what mechanisms you used to authenticate the user in the first place.

2.3. The reset link

This is one of the better (and, thankfully, more popular) mechanisms. It involves authenticating the user, then emailing them a one-time reset link. Once the reset link is used, the user is prompted to set a new password. Once that's been done, the link is invalid. Further security can be provided by including expiry times on the links, and enforcing that the link is invalid after the password is set or after the user's session times out.

The downfall of this method is when we remember our earlier assumption. The user's email account is not safe. It does not count as "something you know". Whilst an attacker's time window is short, they can still break in. Of course, all of this is further invalidated if (or, rather, when) the user forgets their email password.

2.4. Never leave the site

This is the holy grail, really, but can only be used alongside strong multi-factor authentication. Once the user authenticates themselves using a combination of security questions, out-of-band checks (e.g. cellphone), key files, biometrics, human verification, etc. they are immediately redirected to a password change form. This entirely bypasses the need to use email addresses at all.

If you truly believe that using an email address to send a link to is necessary, consider offering a no-email reset option which increases the number of checks that you require to be passed.

3. Conclusion

It's difficult to balance security, usability and reliability at the best of times, but this situation is directly dealing with a user that has already proven themselves to be unreliable. I'm not saying this in any kind of deprecating sense, but rather that we are all fallible.

It's important to keep a password reset system usable and simple, without skimping on security. Before implementing a massive 3-factor authentication process on every aspect of your webapp, think about what you're protecting. If you're just a small company selling things online, you can probably get away with basic 2-factor on recovery. If you're a major retailer, bank, or social networking site, you should be using strong 2-factor on recovery (multiple types of each), and 2-factor on logins from unrecognised sources.

In a sentence: keep it simple, think about your audience.


Meltdown - PoC - Reading physical address with KASLR disabled does not work

OK figured it out. Based on this:

https://github.com/IAIK/meltdown#frequently-asked-questions

With 4 cores I installed and ran the stress utility:

stress -i 4

And was able to read the memory with my two PoCs I had.

Yes, the physical offset was 0xffff880000000000


Is it safe to store data of small company in MySQL database on webhost?

The decisive factors here are isolation and the principle of least privilege. If the account used for the website has access to the database containing the customer records, any compromise on the website is automatically a compromise on the customer records, too. Furthermore, the data could be isolated on a separate server or even a separate network, and accessed using different credentials or different type of authentication.
Securing the data, especially personally identifiable information (PII), isn't only preventing unauthorized access, but also being able to audit who has accessed which data and when. If e.g. the API logs this information, direct access to the database must be limited in order to keep the audit records trustworthy.

This automatically means that offline data should be accessed via internet

I assume by Internet you mean it would have to be either a web application, web based API or at least a connection that is made directly over the internet. This isn't automatically true: you could have additional layers e.g. you could require that the website/API/database can only be accessed through a VPN tunnel.


Can ipopts be used to circumvent a pf or iptables firewall source IP based blocking?

I don't know specifically whether it can bypass these particular firewalls, but my superficial impression is that most firewalls block source routing, specifically because of these kinds of threats.


If you are using OpenSSL below 1.0.2g 1.1.0m (both Nov. 2017) or 1.1.1 (Sep. 2018) there was a bug that did this -- see https://unix.stackexchange.com/questions/393601/local-ssl-certificates-in-chrome-ium-63/ -- and my workaround at https://unix.stackexchange.com/questions/371997/creating-a-local-ssl-certificate is to specify in the CA config section (your [CA_default]) or on the command line the name of an extension section that doesn't actually contain any extensions.

Although if you use v3 certs, in most applications you should have at least BasicConstraints and KeyUsage extensions, and maybe some more, and those usually make more sense to be specified in the CA config rather than in the CSR, because they are mostly not subject-dependent.

Also, most reliers haven't accepted cert signatures using MD5 for about a decade now, and many have more recently stopped accepting signatures using SHA-1 as a result of 'shattered', about which there are numerous other Qs already, and now 'shambles'. Plus assuming your CA key is as strong (large) as your EE key(s) as it should be, neither of those hashes was ever recommended in combination with RSA-2048, whose strength needs at least SHA-224 to match, and nearly everybody (for example all 'real' public CAs) uses SHA-256.


Should 'openssl verify' recognise an exceeded 'Path Length' constraint on a root/intermediate CA?

The pathlen constraint is only valid in subordinate CA certificates.

If you followed the first article you linked and generated a trust-anchor with a pathlen constraint then it is not checked.

According to RFC5280 section 6.1.4 (k) basicConstraint is only checked in certificate i+1 (where the trust-anchor is the first (i=1) and subsequent certificates in the alogrithm are i=2, i=3 and so on).  That is, don't check it in the trust-anchor, only check it in subordinate CA certificates.


You've got the main idea correctly: if you fear that your ISP would sniff or manipulate your traffic then a proper VPN will protect you against this. But then you have to trust the VPN provider instead. Only that you often have more choice in choosing a VPN provider than an ISP and that VPN providers might actually want to excel in terms of privacy while your ISP might have different interests.

But note that a VPN might protect you less than you think, i.e. watch out for IPv6 leaks or DNS leaks caused by improper VPN implementations or configurations.

  I have read that using a vpn can prevent hackers ...

The VPN provider can only protect your connection between the VPN entry (usually your system or your local router) and the VPN exit. The VPN exit is usually not the endpoint of your connection, i.e. there are still MITM attacks possible between the VPN exit and the site you visit. And a VPN will also not protect you against a malicious or otherwise insecure web site. But you've bypassed at least your ISP and if the VPN exit is outside the reach of your government you increased your chance to bypass your government too (as long as the trust in the VPN is actually justified).


First you have to check which process is running or using that port. How can you do that:

netstat -a -b

You can use also TCPView.

Than make sure that running process is not affected by any security issue.

Attackers are just scanning randomly and trying to find new victims.

To keep them away use firewall or IPS/IDS.


Is implementing an SSL proxy server considered a good practice?

According to Mozilla Telemetry half of the top results in the Google search used https in 04/2017 and they projected a further growth to 65% at the end of the year. And while it was once kind of used as an indicator of trust into the content of the site itself, https is now ubiquitous enough to protect traffic to sites delivering malware or phishing, either because they were setup this way or because a formerly harmless site was hacked.

This means content delivered through https cannot be trusted just because of the https but needs to be inspected like any other potentially malicious content. Such inspection can be done either at the endpoint of the encryption or in between. In the latter case one uses for example enterprise firewalls offering SSL interception but also many desktop AV have local proxies doing SSL interception. The other option would be to analyse the content only after decryption, for example using extensions inside the browser which have access to any decrypted content or analyzing any file access.
These different methods of content inspection don't have the same capabilities because they work on different data, have different communication context and are applied in environments which are differently trusted, i.e. the different methods have different advantages and disadvantages.

Doing SSL interception in the perimeter firewall gives visibility into both incoming and outgoing data at the network level. This provides a broader picture of the network where data to different systems can be analyzed together. It helps also to detect or restrict botnet communication. And, while basic blocking of whole web sites can often be achieved without SSL interception more granular control, like blocking only posts to Facebook, can only achieved by having access to the content. The biggest problem with SSL interception is that it destroys the expected end-to-end encryption of the traffic and can actually weaken the security if not properly implemented. And unfortunately, often it is badly implemented.

Analyzing the decrypted content in the browser instead is not really less invasive than doing SSL interception and adds some additional problems. To be effective in detecting and blocking malicious content the browser plugin needs to have access to any content in the browser before it gets executed by the browser. But, this is code running on a system which should be treated as less trustable as the firewall since attacks against clients with their huge attack surface are much more common and successful than against a firewall. Thus one has to consider the case that an attacker find a security problem in the plugin and can either  disable it or worse hijack it to control everything in the browser.

Detecting potentially malicious content with file system monitoring, system call monitoring or similar provides some advantages because it monitors the malware in real action instead of only doing static analysis or running short test inside a sandbox. But it also loses a lot of information about the communication context in which these activities happen, i.e. where does the content come from. Also, it is impossible to detect the typical phishing sites this way which just trick the users into providing their passwords. Apart from that it might actually increase the attack surface too since these monitoring solutions usually run with elevated privileges but are far from bug free.

In summary: Like other kinds of content analysis SSL interception has its advantages and disadvantages, i.e. it increases the security while also decreasing it in a way. But, properly implemented and used the increase in security will outweigh the decrease in many use cases.  And, while there are other ways to fight malware and phishing they have their own advantages and disadvantages and are not necessarily better than SSL interception. Also, it is for example useful to have both central SSL interception in the perimeter firewall and desktop AV as part of a defense in depth strategy.


How can I know why Nmap identified a service or OS the way it did?

Ok, let's see if I can help:

OS Fingerprinting

At default verbosity, the OS fingerprinting engine provides the line number of the matched fingerprint in the nmap-os-db file in the XML output as the "line" attribute of the "osmatch" element. (For IPv6, this number is the ordinal group within the classifier. Because of the machine-learning approach, it's harder to see why a particular scan matched a particular OS group.)
With -v2 or higher or -d, the exact fingerprint (observation) that was used to match is printed in Normal and XML output formats.
Sometimes an OS will be printed on a "Service Info" line in the Normal output. This comes from the o// template in the nmap-service-probes file. The XML output has this info directly under the "service" tag as the "ostype" attribute. More on this in the next section...

Service fingerprinting

At default verbosity, the service fingerprint (exact probe responses) will be printed if no match is found and you did not reduce version intensity with a command-line option (--version-intensity or --version-light).
The --version-trace option turns on lots of interesting Normal-mode output regarding which probes are sent, and which ones match.
The --packet-trace option can print exact hex dumps of what is sent and returned.


So

A ----- says wants to contact B ----------------------->  B

A <---- encrypt some challenge with his private key ----  B

A ----- decrypt the challange with B public key
    encrypt the challange with A private key
    encrypt the challange with B public key
    send both to B ------------------------------------>  B

    decrypt the challange with A public key   ---------   B
    decrypt the challange with B private key
    they are the same? ok, so I could open a
        a message to me (good) that was sent
        from someone who have the A private key.

Problems with that:

Does B have the public key from A?
If not, where does he gets it ? (answer: some PKI ?)
If yes, is he sure that the keys belongs to A? (answer: certificate)
and he verifies that A's key is valid (answer: CRL or OCSP)
Does A have the public key from B? The same questions apply.

Doing those verifications, it would work. Not doing then means that you'd have a problem with:

A not knowing that he contacted B
B not knowing he received a message from A


Invalid OCSP signing certificate in OCSP response

It seems their OCSP-cert has expired on September 10th.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 132 (0x84)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=NL, O=Digidentity B.V., CN=Digidentity Services CA - G2
        Validity
            Not Before: Sep 20 10:40:55 2012 GMT
            Not After : Sep 10 10:40:55 2014 GMT
        Subject: C=NL, O=Digidentity B.V., CN=Digidentity OCSP

Code
I used these three commands:

$ openssl s_client -connect www.acm.nl:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > acm.pem

$ openssl s_client -connect www.acm.nl:443 -showcerts </dev/null 2>/dev/null > chain.pembundle

$ openssl ocsp -issuer chain.pembundle -cert acm.pem -url $(openssl x509 -noout -ocsp_uri -in acm.pem)
Response Verify Failure
2676036:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:126:Verify error:certificate has expired
acm.pem: ERROR: No Status found.

More Detail
Use this instead of third command for more detail:

$ openssl ocsp -issuer chain.pembundle -cert acm.pem -text -url $(openssl x509 -noout -ocsp_uri -in acm.pem)

Link
I copied the commands from here: https://raymii.org/s/articles/OpenSSL_Manually_Verify_a_certificate_against_an_OCSP.html


The tpm2-tools does not provide trusted boot by itself. It provides tools to play with the TPM.

What you are looking for is really either DRTM or SRTM (Dynamic, Static Root of Trust for Measurement). As you pointed out, tpm2-tools won't change the PCRs but both SRTM and DRTM have this capability. They feed the PCRs in the TPM.

DRTM is typically the best way to go and this means the tboot software. There's many tutorial to get tboot running. At the end, what you'll be looking for is for PCRs 17 to 20 to be filled.

I suggest reading this answer and kernel.org doc.


Home banking site request, it possible for a small web agency?

Unless you already have experience in the field, then yes, this is too complex for a small web agency.  PHP can be used securely, but you have to know what you are doing.  As part of a small web agency, I worked on a high security system to manage a bill payment service with many similar requirements to an online banking system.  The project never reached completion due to the client running in to internal troubles with their business, however it was fully possible to do and we were making excellent progress until the client's business went under.

The problem is that if you don't already have an in-depth knowledge of secure programing and either know, or have someone who knows the banking regulations you need to follow, producing a technically and legally compliant solution is going to be exceptionally time consuming and difficult.

The project I worked on only stayed on schedule because the client understood the legal requirements for the system and I knew how to securely implement such features already.  (The need for such a secure developer was actually what got me involved with that company in the first place.)

If you want to try taking on such a job, you will want to find someone local who has a background in writing secure software and work with them on the project.  It isn't all that difficult to implement a secure site with basic functionality, but it does require a lot of knowledge and understanding that goes beyond what we can provide in an online Q/A format.


What's the meaning of the term "ad-hoc MAC" (Message Authentication Code)?

Ad-Hoc Communication is the process by which participating Nodes(Machines) can transfer data between them directly without a centralized server. MAC can refer to Medium Acces Control

MAC Code is a unique identification code assigned to devices communicating in adhoc mode to identify each other.
MAC can also refer to Message Authentication Code  which is used to authenticate messages as well as to preserve integrity.Hashing and Encryption is used to achieve this.

So Adhoc MAC Means the Code used to authenticate messages between Nodes in an Adhoc network.


OAuth2 - Authorization Code Flow - Do I really Need this for simple login/authentication?

seems to suggest that it is required

  do I need to implement OAuth Authorization Code flow ... ?

I suppose that your understanding of software development is not correct.

Who requires you to implement that?

As far as I understand you control both sides - client and server. Then it is you who decides what should be done. If you develop software for some customer and this customer gave you the list of requirements, and this includes OAuth2, then it is really required. Or you are developing clients (mobile, SPA) for some existing server application which only supports OAuth2. Then you are really required to implement OAuth2. Otherwise it is not required. It is up to you what authentication mechanism you implement.

What should you do? Take several solutions and compare them from different points of view: Security risks (what are possible attacks, how probable they are, what can be the costs in case of successful attack), the complexity and the costs of implementation of each method, the costs to maintain it, the costs of support, usability, performance, how much money you can actually spend on it, etc. Then you will see what is the optimal solution in your case.

Update

There is no THE best practice. I have to repeat that: it depends on the context, it depends on what are your risks, on what are you requirements to usability, on what price can you pay, etc. This is very naive to look for simple answer.

In many companies the best practice is to use simple one step login where each application is itself responsible for the authentication. Any login issues are analyzed and resolved much quicker than in case of other solutions.
In many companies the best practice is to have a separate service for authentication, e.g. based on OAuth or based on JWT.

In many companies the best practice is to use 2F authentication based on OTP token like RSA SecureID token.
In many companies the best practice is to use 2F authentication based on authenticator app like MS authenticator or Google authenticator.
In many companies the best practice is to use 2F authentication based on tokens like YubiKey or Titan.
In many companies the best practice is to use 2F authentication based on photo TAN.

There is no THE best practice.

One of the very secure methods is using of 2F auth. with RSA SecureID or YubiKey. Are you or your customers ready to buy an RSA SecureID or YubiKey for every user? To pay for corresponding infrastructure? To pay for support (you need a stuff that will support users, answer their questions, analyze their cases, reset their blocked accounts, etc.)

Is it too expensive to you? This is important constraint. Then write that in your question, that your budget is limited with X USD

I mentioned usability. Is it too complex for your users? Do they want to have simpler login process? Then 2F is not for you. But again, write that in your question that usability has very high priority.

Do your users need SSO? If they do, then with OAuth or JWT you have SSO out-of-the box (the amount of code to implement is relatively small), where as with other mechanisms you have to implement much more. So OAuth or JWT can be preferable in such case.

What is your requirement on performance? Depending on your requirements and your infrastructure it can be that OAuth is too slow for your requirements. Test it on your real environment with some realistic load (number of users per second). Then you will see if OAuth fits your performance requirements.


How to verify Ruby on Rails projects are at current patch levels?

What you describe is a security nightmare in itself - multiple environments at unknown (effectively thus undocumented) versions, with no central registry what to update if necessary.

So, that's in itself worthy of reporting.

Now, your job becomes making a map of all the installations; run your commands on each of these (automatedly), and make a report out of that as well as integrating it in whatever infrastructure for server management (vagrant? Ansible? Puppet?...) You guys use. Congrats!


What technologies does ChromeOS use to secure saved passwords?

ChromeOS is build on Linux only, so the developers take the advantage of the existing solutions available for encrypting the user data AND make it automatic and mandatory.

If we talk about options available to ChromeOS developers (because of the fact that it was built on Linux) was --

Block based Encryption
File System based Encryption
Whole disk Encryption
Whole data partition Encryption

File system based encryption was chosen for encrypting the home directories of all the users. Encrypting user's home directories means all the data (including cached history, cookies, saved passwords, and other) will be encrypted by default and will be transparent to the user.

If we talk about specific tool (or package) which ChromeOS uses to encrypt the saved password (as saved passwords are also stored in the user's home directory), eCryptfs (Enterprise Cryptographic Filesystem) is a package which do the encryption in ChromeOS.

Hope this explains your query.

References -
1. https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data#Appendix_D_Designs_considered


If there is a TCP unencrypted packet sent to and encrypted data streaming APP what would happen?

Would it get modified with the decryption key and the then the application will try to run the code making error because it does not make any sense Or what what will be the result?

There is nothing inherent in TCP which would make an application run any code send by the other side. TCP is just for data transfer. But of course there could be an application protocol on top of TCP which is used to send code to the other side of the connection and this other side could then execute the code.

The behavior then depends on this application protocol and how it deals with encrypted data. If it uses for example TLS as encryption layer and tampering with existing packets or injection of new packets will be noticed. But if you design your own application protocol and ignore such kind of attacks you might create a protocol which is vulnerable to such injections.


PBKDF2 used to generate an encryption key: long shared secret (password) vs iterations count

The AS/400 line of machine has a long history. They normally use CPU from the PowerPC / POWER family, but the first models began with CPU clocked at 55 MHz, which you cannot expect to be fast... This might explain the abysmal performance that you get. Or perhaps there was some subtle issue in your porting process. For instance, aggressive loop unrolling may make a function code exceed L1 cache, which can kill performance big time (I already witnessed a 50x slowdown for such cases).

Anyway, the iterations in PBKDF2 are meant to compensate for the relatively low entropy of the input password (because the password is a password, fitting in a human brain). If you can arrange for the password to have high entropy, then you will get security with a low iteration count.

(Mind that entropy is not length. Entropy is randomness.)


Secure way to pass client certificate to the client2

You do not want to generate a client certificate for your customer.  This would mean that you have the private key for their communications.  This is bad practice.

You kind of have the right idea.  You want to generate a Root CA Certificate for your main server.  The customer would then generate an Intermediate CA Certificate for their server.  They would send this Intermediate CA cert to you via a Certificate Signing Request (CSR), and you would sign the certificate with your Root CA cert.  The previous link is for informational purposes only, I'm not advertising their product.  This signed certificate would then be sent back to the customer for use.
A CSR is a format that contains all the information needed for you to sign the certificate provided.  It does not contain the private key of the certificate.  This answer and comments explain that a form on a webpage for submission is reasonable because there is no private data being passed.  This will also give you a chance to gather other needed information to verify the customer in order to process the CSR.  Once you've processed the CSR you can send the certificate back through the same means, by email, or whatever method you choose.  There is no private information added after you've signed their certificate.
Yes, OpenSSL provides all the functionality you need to set this up.  There are several examples of PKI setups on OpenSSL PKI Tutorial.  Here is another great walk through for PKI creation (PDF).  Now these examples go beyond the scope of what you're doing, but it will give you the full understanding of what needs to happen for certificate authorities to work.

Here is a nice explanation of how the things all fit together at a higher level.


What is the fail2ban default setting for SSH login attempts?

I think you are seeing a combination of two things:

Latency between the time sshd sends the string to the log, the time syslog writes it to the disk, the time fail2ban picks it up, parses it, and and injects an iptables rule into the running set, and the time the kernel starts paying attention to the new filtering rules. This is why you see "Already banned" entries in fail2ban.log.
PAM, login.defs and sshd all trying to block successive retries. If you notice, it says sshd[9280]: PAM service(sshd) ignoring max retries; 5 > 3, which PAM telling you that there is "retry=3" in one of its modules (probably /etc/pam.d/password-auth) and it will ignore any further authentication requests from sshd within the same session. Sshd will continue trying until it exhausts MaxAuthTries setting (default is 6, I think), at which point it will terminate the connection. This probably creates different log entries that fail2ban doesn't parse as failed login attempts. Just a guess on this one.

HTH.


Best ways to store a password Server side

Matching color and number? Are you sure that information is stored rather than calculated? I suspect only a password hash is actually being stored. The rest is probably determined on the fly by a client-side algorithm. You should only store, and can only verify information that is input by the user. Unless the user is selecting a color or image as part of the authentication process, that's probably just a flashy interface and not an authentication method. Your question needs more clarity on that for those of us who don't work with Lotus on a regular basis.


Are longer passwords safer even if the encryption/database security used is compromised?

A few general cases for offline attacks (they steal the entire username and password hash table, including salts, peppers, etc.:

Weak password, ANY storage - it's broken.
ANY password, plaintext storage - it's broken
ANY password, encryption storage, keys lost or weak too - it's broken (HASH IT)
Moderate password, weak but correct hash storage - it's broken.
Moderate password, very strong and correct hash storage - it depends on the time and resources the attackers put forth

This includes AFTER the original attackers give up and post everything on the Internet for everyone in the world to take a crack at.

Extremely strong password, weak but correct hash storage - it's safe!

and so on between these.


What is the difference between "cipher" and "encryption"?

"Cipher" is the algorithm or process used to encrypt the data (i.e. AES, RSA, etc.). "Encryption" is the process of converting data using the aforementioned cipher.


Are the encryptions "broken" with great computing power?

Public-key cryptosystems base their security on certain assumptions, one of these being that certain mathematical problems, while theoretically solvable, are computationally infeasible to solve. Typical examples are integer factorisation and the reverse logarithm problem which are used in cryptosystems such as RSA, DSA and Elgamal. For example, an attacker that had infinite processing power, memory and time, could derive a private key only by having a public key.

Quantum computers work with qubits instead of bits, which means that each bit could be in either 0, 1 or a superposition of these states simultaneously, in contrast to classical computers where each bit can only be in one state at a time. This leads to what is called quantum parallelism.

The real issue is to find how to utilise this parallelism to solve mathematical problems faster. Certain tasks, such as multiplication, cannot be performed much quicker by this kind of computer, while others, such as integer factorisation can. Algorithms such as Shor’s algorithm exploit the power of quantum parallelism to perform integer factorisation in exponentially less time than normal computers. For example factorising a 1024-digit number which would take billions of billions of years, with a quantum computer it could take 20 minutes. This means that cryptosystems such as RSA that rely on the computational infeasibility of breaking an integer into two primes will be considered obsolete if a quantum computer (that can handle such computation) is built.

For this reason, cryptographers are already researching what would happen in a post-quantum era and have been trying to find how to build public-key cryptosystems that rely on problems that cannot be solved by quantum computers any quicker that classical computers.

Finally, it should be stated that symmetric cryptography is thought not be affected so much by quantum computers. By using a quantum computer, Grover’s algorithm can make the search for a key quicker by needing the square root of the time of a normal brute-force search. This is significant, but it is suggested that simply doubling the key length is enough to mitigate the attack.


Will reporting phishing emails cause problems for the victim?

If you report it, Google actually are pretty good at figuring out issues and if it is in their control, they can take some action, however what may happen is that the individual may get blocked from communicating...which helps solve the issue of phishing emails being sent. This can be sorted out though, so do not let it put you off reporting.

Conversely - if you do not report it, what will happen? The phishing will continue and some individuals may be scammed.

Best bet - talk to this person, they may be entirely unaware, so informing them can allow them to do something about it. If they don't take action, or the problem isn't at their machine/account etc then think about escalating.


On an "uncritical" site, is there any reason to NOT trust a self-signed certificate?

Firefox had once a bug, where the trust was not applied to site+certificate, but to the certificate only. E.g. if you had a self-signed certificate with a common name of example.org but a subject alternative name of paypal.com and the user visited your site example.org and accepted the self-signed certificate, then this certificate could be used to transparently intercept paypal.com, e.g. no more questions asked or warnings issued.

Bugs like these tend to resurface from time to time (especially when somebody writes a new TLS stack) so accepting self-signed certificates can lead to serious problems.

Apart from that,  using self-signed certificates just teaches people to ignore these security warnings (which most don't understand anyway).


LDAP vs MySQL for Usernames and Passwords

Privilege Separation Principle

This is a classic case where isolation of your content database from your user database provides a security advantage.

The Application Server knows the users password for the short time until it is compared against the password in the LDAP Server, where it is discarded and only the session and username information is kept for the life of the users session.
The LDAP Server validates the password and delivers the user information to the app server.
The Content Database has less critical information accessed through the app server.

The LDAP Server is not more secure, but it has a limited purpose, and thus the surface area for attack is much lower, as opposed to the typical user table stored in a content database which can be retrieved directly in the case of a injection exploit.

The LDAP Server and the Content Database are hidden (in some architectures) by the Application Server so that direct access is not required and only pass through attacks are possible, further reducing the possibility of compromise.

These multiple services do introduce a complexity that has costs and issues, but they constitute a pattern that encourages/forces the designer/developer to keep separate these specific accountabilities/concerns rather than collapsing the implementation into an insecure system.

Another way of thinking about it is that mistakes are always made when designing / developing / deploying  a system, and without this separation of accountabilities, mistakes made in one domain can bleed into and compromise the other domains.

Note: Through a quick reading of the LDAP protocol, a password is a field in the LDAP database, so if that field is hashed (best practice) then the LDAP database doesn't need to know the plaintext password, and as a commenter notes there are special API's for avoiding issues with password authentication.


How easily could this method of cryptography be cracked?

The point of this Q&A site is not to assess people's algorithm strength, so technically this question is off-topic. However, there are points in here that requires explanation and do point to the algorithm weakness without having to look at it.

As per Kerckhoff's principle, a cryptographic system must still be secure if everything about the system is known, except the key. "What is the key" in your case? And "what is it's length?" are two question you need to ask yourself before even thinking of strength of the scheme.

The network seems to be the real key here. It is based on a pseudo-random generator. So the key is the seed. Which is an int. So 32 bits. That is a poor key.

In addition, having both plain text and it's encrypted form makes it possible to make a known plaintext attack (as mentioned in the comments).

So it's a bad cryptography scheme.

Furthermore, steganography and cryptography rarely goes well together, since they have objectives that are opposed. Cryptography is all about confidentiality (and authenticity in the case of signature), while steganography wants to stay undetected in the mass of information. Steganography does not care about strong resistance to decryption, in fact the algorithm can be published and not use any key at all. The "security" behind steganography is resumed by the following elements:

You have a flow of data (images, ...) that is important
The attacker cannot plausibly try to decrypt each and every data to check for hidden message
The steganography scheme does modifications that are not easily identified in the data

The goal of the attacker of a steganography scheme is to be able to process an image and say : "yes there is a message here", or "no there is no message here".

Typically, cryptography is used to transmit large amount of data. But large amount of data cannot be successfully hidden with steganography in only one media without impairing invisibility.

Furthermore, your scheme increases the number of bits needed to be embedded.

So it's a bad steganography algorithm.