Background
That message is from the basic header that every Windows (PE format) executable has. The message (and the code that displays it) is technically editable, but all compilers seem to just emit code that displays that same string and then exits. It's 16-bit executable code (like a DOS .COM file), intended to be displayed when you try to run the program on MS-DOS or similar pre-Windows systems. Windows' program loader typically skips over it.
Explanation
However, there is one case where Windows might display that message: when you try to run a PE that is compiled for a more advanced version of Windows than the one you're using, especially if the main program code is for a different CPU architecture than the OS can support. (This is similar to, for example, trying to run Win32 code on 16-bit DOS.) From a GUI, you'd get a pop-up error, but in the command line, you may well just get that message.
The obvious candidate here is that you're trying to run code on the (hideously obsolete) Windows XP, and you say you're using "i686-w64-mingw32-gcc". If you're compiling 64-bit binaries for Windows XP, it's extremely likely they won't work; while a 64-bit build of XP technically exists (it's actually a different kernel version, 5.2 vs. 5.1, but it's branded as XP), it was never widely used; the extremely vast majority of XP boxes are 32-bit only. If you want a quick check for 32-bit vs. 64-bit from the command line, check for the presence of a \Windows\SysWOW64 directory (which holds 32-bit system binaries on 64-bit machines); if it doesn't exist, you're running on a 32-bit OS.
Recommendation

Unless you A) need 64-bit for something, and B) know your target is 64-bit, only use 32-bit payloads.
Make sure your code and compiler are targeting XP (Vista and later added a ton of new APIs that will prevent a program which uses them from running on XP).
Consider spinning up an XP VM to test whether your payloads run locally before trying them on the target machine.


WYSIWYG Rich text editor and renderer with no XSS risks

First of all - the use of the security mechanisms that you have described before is a good practice.

State-Of-The-Art XSS Sanitizers

DOMPurify

CURE53 (a leading group of security researches), created a client-side JS library that's called DOMPurify. You can use it as "sanitize(string)", that allows you to enter code and clean (sanitize) it, based on rules that you describe.

Caja

Caja is a similar tool from Google.

Both of Caja and DOMPurify are sanitizers only. However, they are super easy to use, and considered State-Of-The-Art in regards to HTML sanitation.

A Quick word about Iframes

Please keep in mind that using different domain (not only sub-domains) sandbox Iframe is a great practice, but not enough. Please beware of other pitfalls, such as using insecure window messages between the Iframes

A Quick word about CSP

I would like to encourage you to test your CSP in Google CSP evaluator (unless you are familiar with that already).


How are Cloud based HSMs used for Encryption by an application that is on premise (behind the enterprise firewall)?

In most cases, you would install the driver/engine software in your servers and would do PKCS#11 over TLS.

Be aware that some vendors' offering may not be a true HSM; specifically it may be the software and management around an HSM delivered as a virtual appliance. These are not meant to provide the same level of resilience to attack as a true HSM. The key-store is an encrypted file on the virtual appliance, and not an encrypted NVRAM inside a blob of epoxy. This means in theory, it could be repeatedly cloned for massively parallel offline cryptanalysis. As such, these virtual appliances will not receive FIPS-140 certification.

I cannot say which of the first-tier vendors I got this from, nor can I go into more depth, as some things are covered by NDA, but I would work closely with your employer's risk management team and audit to determine whether it is an acceptable risk to outsource.


Should I show the security answer when the user goes back to edit the field?

Assuming this is all done during the enroll process, which it sounds like it is, there isn't a lot of risk associated with displaying the plaintext answers to the user.  It's pretty unlikely that an attacker will be able to hijack a user's session mid-enrollment in order to see the security question answers.

However, it doesn't seem like it would be terribly inconvenient for the user if you blank out those answers.  I suppose a small percentage of people might go back to edit them in order to make sure they recorded the answer they thought they did moments ago, but they could also just retype the answer they wanted.  So if it makes you feel better to blank them out there probably won't be a lot of user frustration associated with that practice.

If a user can log into the app at a later time and edit security question answers then my advice would be to not display the current answers since it is more likely that an attacker could hijack a normal session (or find a logged in browser) and copy the answers.

It sounds like your plan to hash the answers would make that functionality impossible in your app anyway.  That practice, by the way, is likely to cause you some usability problems since people may not type in their security answer exactly the same way during enrollment and later during use.  Some implementations of security questions encrypt answers instead so they can make looser comparisons (e.g. not case sensitive, ignore trailing spaces, etc.) and be more user friendly.  That is a bit less secure, but it is a tradeoff some people are willing to make.


How to get hold of and use WPA session keys?

In Wireshark, filter for "eapol" packets. You can read RFC 4764 to figure out how to derive the encryption key from those packets, or look at the Wireshark decryption source code.

They say this exchange pattern is for the sake of simplicity, though I consider not using a Diffie-Helman exchange to have been foolish (see section 1.1.1).


The simplest reason is likely that the outgoing traffic is not going out that interface. Are you sure there's traffic to capture?

Do you have more than one interface connected on this system? If so you may have asynchronous routing, where incoming and outgoing traffic go out separate interfaces. Look at your routing table using netstat -r (should work on most OSs), and look at which interface is the best route for that host. If the traffic is being routed out another interface either fix the routing issue or do a packet capture on both interfaces at once.

Another possibility is that you are filtering out the traffic you are looking for. Make sure all capture filters are off, than do a capture. Stop the capture and then filter the results. Try using ip.host == "x.x.x.x" and see if you've captured both the incoming and outgoing.


IoT Devices and 39 Month TLS Certificate Life

Large edits because now it is clear that OP is asking about devices which only work as a TLS client...

If this is only for client devices than you don't need to update the certificate on the device since there is no certificate on the device. The certificate is on the server (which you need to update) and is checked against the root-CA on the client device. With this root-CA it will accept all certificates issued by this CA, even future certificates. Which means you depend on the same CA issuing certificates within the life time of the device. You might still need a secure way to update the firmware in case yet another buggy TLS stack happened or regulations require the use of better cryptography within the 10+ years time frame.

Yes, you need to have some secure way to update the certificate for this device. One reason is the 39 month limit, another is a possible compromise of the public key used for the certificate (how it is protected anyway for such a long time?).

And given all the recent bugs in TLS libraries you better have a secure firmware update too. Apart from that you either need your cryptography ready until the end of the 10+ years time frame or you need to have ways to upgrade the algorithms and protocols in use. Note that within this long time frame  TLS 1.0 and TLS 1.1 will probably get deprecated, as do 2048 bit RSA keys. It might also be that the not yet released TLS 1.3 will be already required.

  Will it only be the servers's certificate I need to replace and not the root CA on the device?

The Root-CA on the device is only needed if you make TLS connections from the device. If you need to do this then you probably will need to update these root-CAs too because several root-CA will expire within this time frame so you cannot verify connections any longer.


How difficult to crack keepass master password?

KeePass uses a custom password derivation process which includes multiple iterations of symmetric encryption with a random key (which then serves as salt), as explained there. The default number of iterations is 6000, so that's 12000 AES invocations for processing one password (encryption is done on a 256-bit value, AES uses 128-bit blocks, so there must be two AES invocations at least for each round). With a quad-core recent PC (those with the spiffy AES instructions), you should be able to test about 32000 potential passwords per second.

With ten random characters chosen uniformly among the hundred-of-so of characters which can be typed on a keyboard, there are 1020 potential passwords, and brute force will, on average, try half of them. You're in for 1020*0.5/32000 seconds, also known as 50 million years. But with two PC that's only 25 million years.

This assumes that the password derivation process is not flawed in some way. In "custom password derivation process", the "custom" is a scary word. Also, the number of iterations is configurable (6000 is only the default value).


Protecting users with browser extension. Is it possible, if the machine is already infected?

If a process (or a user, for that matter) acquires administrative privilege on a machine, it is able to do anything. Included replacing a browser extension with a malware browser extension without the user knowing it.

Any security mechanism implemented inside the machine can be nullified by the malware. For instance, your homemade extension could verify its checksum to ensure it has not been tampered with; however, it would be trivial to include in the tampering code a check to falsely pass the checksum test.


There is no obvious difference in transporting malware directly as attachment or let the user retrieve it by visiting a link within the mail. But it might make a difference depending on which other security policies and tools are in use in your company:

If the mail is not encrypted and the link does not point to an https side it might be better to use links, if the firewall (which you hopefully have) is able to protect against malware on the web, but not or less capable to do the same for mails.
If you allow and support encrypted mails (PGP or S/MIME) the firewall is usually not able to look into the mails, because they would need the private key of the recipient. So links might be safer, especially if the firewall is also able to intercept and analyze https traffic (most better firewalls do).
If you have a policy of not sending attachments within mails it might be accompanied by a policy to not accept attachments in incoming mails. This would make it easy to weed out lots of malware (or even targeted attacks) which you get today as mail.
The policy of not sending attachments can be accompanied by a central storage which you have to use instead of attachments. With the right permissions on the folder you can trust the links to the storage you get, because only authorized (and trusted) users have access to it. This is in contrast to mails, where you can easily spoof the senders address so that you cannot trust the sender info of the mail.

In summary: with the right security concept behind it such a policy might actually make sense.


Need Help! Computer Hacked!!!! Need to protect data

You can't. There is no way to make a computer hack proof. And with the very limited information provided in your question, there is no way to give you specific advice about your situation. Here is some general advice to start you on the road to hack proof:

1) Get a new ISP. If you think your ISP is attacking you, then immediately disconnect your router, terminate your internet service contract, and purchase a new one from a different company.
2) Completely wipe your laptop. Use DBAN (https://dban.org/) and do the seven level wipe to completely rid your hard drive of any information you have. Then destroy your computer (there could be rootkits installed that have fundamentally compromised your machine).
3) Buy a new computer (Puri.sm is a good start) and use an operating system like QubesOS (https://www.qubes-os.org/) to better protect your computer. If you need to use Windows, do so from a virtual machine from a Linux computer and use snap shots to revert it after every use.
4) Setup inbound firewall white listing on every level of OS (hypervisor, main OS, and vms). This way, only connections you explicitly allow can get from the internet to your computer.
5) Use encrypted, private email (like ProtonMail). Create a truly random password with at least 16 characters (recommend much higher where possible). Setup two factor authentication. Create one of these emails for every service you'll be using (facebook, twitter, banking, etc) and never let them overlap in any way. Treat them like individual identities that never mix with each other.
6) Purchase and use a VPN. Never access the internet without it.
7) Setup ad blocker, privacy badger, and https everywhere on your web browsers.

These are six pretty difficult things to do and there is quite a bit of financial investment involved. But, if you can do all of these things you will be much more difficult to hack.


Android verified boot within the boot sequence

AVB is enforced by the bootloader and dm-verity is enforced by the kernel. Both run consecutively in android boot flow.
In factory:

OEM constructs hashtree of /system,  /vendor, product and ODM partitions. Hashtree is not constructed for /boot and /vbmeta partitions.

In vbmeta partition, OEM writes hash descriptor of boot image which contains hash of boot image. OEM also writes hash descriptors of other partitions which contains root hash & salt of hashtree.

OEM signs vbmeta using OEM private key and appends its signature to vbmeta image itself. The OEM public key is hardcoded in android bootloader (ABL) at build time.

On boot:

ABL verifies signature on vbmeta using OEM public key.

ABL calculates hash of boot image as it loads and verifies it with the one stored in vbmeta.

After boot.img (contains kernel) is verified, the kernel is loaded and kernel starts dm-verity.

Kernel reconstructs hashtree of every partition except /boot and compares their root hash with the one stored in vbmeta.

If all hashes match, device boots to lock screen.

Chain partition is used for delegate authority like in case of enterprise devices and carrier devices. If an enterprise wants to include additional partitions, vbmeta for chain partition is stored in the footer or if there are multiple chain partitions, a separate vbmeta_enterprise that verifies all chain partitions can be created. It is signed by the private key (key1) of enterprise. The public key (key1_pub) is then stored in original vbmeta partition. This delegate authority can be easily revoked by simply updating original vbmeta image with new descriptors of the chain partitions and removing the public key key1_pub.
The chain of trust for AVB starts from ABL so it's possible to replace OEM public key with your own and re-sign vbmeta by following the same process as done by OEM. To protect ABL from tampering, production SoCs enforce secure-boot. To enable secure boot, production devices have their eFuse blown in the factory and it's irreversible. Fastboot unlock and unlock_critical commands do not turn off secure boot. Even a fastboot command can blow the eFuse of prototype devices which permanently enables secure boot of SoC.
fastboot oem SecureBoot EnableFuse

In Qualcomm Snapdragon SoCs, ABL is verified by Xtended Bootloader (XBL) and XBL is verified by Primary Bootloader (PBL). PBL is burned on CPU die and its public key is stored in eFUSE and thus making it tamper-resistant. Trusted Execution Environment (TEE) is not verified by AVB. It is verified by XBL_SEC (Xtended Bootloader Secondary) which is another bootloader verified by PBL. TEE image is double signed by the chipmaker and OEM. TEE is awaken by XBL_SEC at the same time when XBL loads ABL as shown in picture.

Android Verified Boot 2.0
Android verified boot 2.0 vbmeta data structure analysis
Analysis of Qualcomm Secure Boot Chains
Qualcomm’s Chain of Trust
Secure Boot and Image Authentication (pdf)


There are two primary ways to scan for the IoCs in Yara files:

Against files on disk using a tool such as Loki.exe. Loki requires yara and will scan Windows machines looking for IoCs.
Versus memory dumps available through a variety of memory-dumping tools. The Volatility Framework includes a plugin called yarascan with can specify Yara-rules file by using the -y flag. Many newcomers are now using the Rekall Forensics framework (a fork of Volatility) for its simplicity and extensibility.

Below I combine Loki's signature-base yara folder (full of Yara-rules files) with Volatility against a memory dump I gathered using MoonSols DumpIt.

  for i in `echo /opt/signature-base/yara/*` ; do vol.py --profile Win7SP1x64 -f 110138-E7440-20160328-191617.raw yarascan -y $i ; done

You will likely want to prep your DFIR workstation with a ramdisk in order to gain some performance increases when running analyses such as these.


Need to ephemerally store third-party password

The question to ask is: what is the security model here ?

You apparently need to transmit the user password (a sensitive piece of data) from the user to the back-end servers. But the timing matters: the human user enters his password once, at the beginning of what the user thinks of as "the session", and the password must be transmitted at later times to the back-end (the "API calls"). So there must be some storage somewhere.

PHP sessions are server-side storage, as a collection of small files with time-based expiry. What you write in a "session variable" ultimately goes to the hard disk. Therefore, it could be considered as bad form to store a plain password in a session variable, because hard disk physical contents are not reliably destroyed when the file is deleted (upon deletion, the storage area dedicated to the file is marked as reusable, but the data itself won't be overwritten until the area is indeed reused for another file). But there are details:

If you fear a data leak through post-mortem access to an old disk (or a backup tape), then what you want to avoid sending the file to the physical medium. Some people put the PHP session files on a RAM disk: the RAM disk is setup with the OS facilities for such things, and the path to it is adjusted with session_save_path(). Files in a RAM disk never make it to physical storage, so the leak is adverted. On the other hand, all sessions will be lost if the server reboots (this is probably tolerable, but it depends on the setup). Sharing the session across multiple front-ends would also be more complex.

Note: on Linux systems, there are three ways to create RAM disks: the "true" RAM disks (size up to 16 MB each, adjusted at boot time), "ramfs" and "tmpfs". This last one will use RAM but also swap space, so contents may still hit the disk. See this page for some details.
If you fear leakage of session data through a live hack of your server, then consider that someone who could get read access to some OS-protected file is probably not far from taking control of the complete machine as well, at which point he will just plug into the PHP engine and grab the user passwords as they arrive. There is little point in going to that level of protection.

What you suggest is encrypting the user password, and storing the key in the client browser (as a cookie) and the encrypted password in the session files; or you could do the reverse (key in the PHP session, encrypted password in the cookie). In both cases, the idea is that the attacker needs to grab both the session data and the cookie to unravel the password. This makes sense only if your security model assumes that an attacker would be able to read the session files (even when they are only in a RAM disk) but not the RAM allocated to the PHP engine (through which passwords necessarily travel at some time). This does not seem a very realistic model to me.

If you do want to use encryption, regardless of its apparent uselessness in that specific situation, you may as well do it properly:

Generate the (user-specific) key with a cryptographically secure PRNG (openssl_random_pseudo_bytes()).
Use proper encryption. This means the usual assortment of encryption mode, random IV (to be stored along the encrypted file), padding... which is easy to get thoroughly wrong. It is possible to do correct encryption with PHP, but you have to understand what you are doing down to the fine details. In that specific case where a new key is generated for each encryption instance, it should be enough to use a strong block cipher in CFB mode and a fixed, conventional IV, although it would leak the password length; and PHP has a habit of doing weird things (e.g. its "CFB" mode is actually CFB with 8-bit feedback, which is slow and of questionable security for long inputs).

but I still recommend not doing that, and instead use RAM-based storage of PHP sessions on the server.


How can I make locally stored data unreadable unless connected (logged in) to server?

Ok, I'm no expert in this. Maybe others can add in.
But from your description, this is what I can come up with.

client logs in.
server issues a key, K.
client keeps K in memory to encrypt log on disk as well as decrypt any log read back in memory for viewing.
upon client attempt to log out, or disconnection, key K is wipe from memory.

That way, the client would have no key to decrypt anything in the absence of active session, such as accidental disconnection in addition to logout.
Here, I'm assuming the key K is being sent securely across using something like TLS.

However, encryption scheme is always hard to get right. Let see what others say.


It's a simple question and the answer is even simpler. Yes (but for only half the reasons stated in the comment by KnightOfNi)

(Carrying on for the sake of completeness)

An 'airgap firewall' loosely describes a system not connected to anything else (taken here to also mean no wireless connections). Somehow data is input into the airgapped system and exported from it. Hack that mechanism and you can hack the airgapped system even if it's not connected to the internet.

If a tiny little PLC in a nuclear facility in the desert can be hacked, an ISP (which may or may not have carried a payload used in the attack if the attacker used that ISP) can definitely be hacked.

In fact, if you have physical access to a system, it doesn't even need to be on to be compromised.

If one man made, another man can break it.


VPN doubt about "encrypting" an IP address

A VPN expert with English as a first language did not write those words. It's wrong and meaningless. But I do understand the gist of what the author meant to say. Your IP is hidden from your target and your traffic is hidden from your ISP.
According to the Wayback Machine, this new copy was added some time between Aug-Nov 2020. It looks like it was not properly reviewed... What's interesting is that all instances of this quote in other places start to appear in November 2020.


Can a CMS generated HTML Document from an admin be considered trusted, and not vulnerable to XSS?

If by "administrator" you mean the person with all the rights, then this is fine and not considered a vulnerability. If you also have a more privileged "superadministrator", then the administrator could elevate their privileges to superadministrator via XSS.

There are some vulnerabilities whose impact would be increased by this. For example CSRF would now have the full power of XSS.

You should also document this - WordPress eg documents this as well - , so that people are aware of it (and so you don't get reports about issues which you do not consider vulnerabilities).


Hashing, or really a Message Authentication Code (MAC) in this instance, would not be used in encrypting the message per se, but would be used to verify that the message had not been tampered with while in transit.

A traditional hashing function is a one-way function which takes an input (the text of your SMS message, in this case) give a unique output for that input.  The same hashing function applied to the same input will always product the same output.  A good hashing function is one that is mathematically easy to go from input to output, but is mathematically difficult to go from output back to the orginal input.

A Message Authentication Code is similar to a traditional hash in that it's difficult to go from output back to input, but it also takes a private key.  This means that two users can take the same MAC function, put in the same data, but get two completely different results if the private keys do not match.  The recipient of the message can then use the senders public key to validate that the sender was indeed the person that sent the message.

Building crypto systems is very hard to do correctly.  If you need to communicate securely by phone, I would recommend that you use an existing, peer-reviewed app such as Signal.


Is branch predictor flush instruction a complete Spectre fix?

A predictor-flush instruction is necessary but not sufficient for protection from Spectre.  A full protection against the Spectre attack requires two things:

Flushing the branch predictor state on context switch.  This prevents one process from attacking another by giving each process its own branch-predictor state.  It does not, however, prevent a sandboxed component of a process (such as JIT-compiled Javascript) from attacking other components of the same process.
Branch predictor state must take the full address of the branch instruction into account (currently, to save space, only the low-order bits are used).  This will prevent a process from attacking itself, since different parts of the process must have different addresses.  It does not, however, prevent one process from attacking another, since different processes may use the same address.


Qualys SSL Scan weak cipher suites which are secure according to ciphersuite.info

The information on ciphersuite.info is not presented in the clearest of ways. Let's have a look at their FAQ:

What does insecure, weak, secure and recommended mean?
Weak
These ciphers are old and should be disabled if you are setting up a new server for example. Make sure to only enable them if you have a special use case where support for older operating systems, browsers or applications is required.
Secure
Secure ciphers are considered state-of-the-art and if you want to secure your web server you should certainly choose from this set. Only very old operating systems, browsers or applications are unable to handle them.
Recommended
All 'recommended' ciphers are 'secure' ciphers by definition. Recommended means that these ciphers also support PFS (Perfect Forward Secrecy) and should be your first choice if you want the highest level of security. However, you might run into some compatibility issues with older clients that do not support PFS ciphers.

So to be frank: Weak means these have problems and should be avoided at all cost. Only enable these if you know you really really have to. Secure means they're not technically broken, but they also don't offer any desirable features. Recommended means these are the ones you should actually use.
I would disagree with their statement about incompatibility. The only clients that do not support modern ciphers are already outdated clients and no longer supported anyways. These clients should be dropped unless you have a very good reason to support them.
Why are these ciphers in particular considered weak?
As Soufiane Tahiri pointed out in his answer, CBC ciphers and RSA ciphers are not considered state-of-the-art anymore.
CBC ciphers have quite a lot of problems, such as the mentioned Lucky 13 attack, or other side-channel attacks. CBC also violates Moxie Malinspike's Cryptographic Doom Principle:

If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

GCM, for instance, does not violate this principle, so it is vastly preferred.
RSA on the other hand does not support forward secrecy, which is a VERY useful feature when it comes to cryptography. Basically, with RSA, the server sends its public key, the client generates a random secret, encrypts it with the public key and sends it back to the server. The server then decrypts it with its private key. The following graphic from the Cloudflare Blog illustrates it well:

While this looks simple and secure, it does have one glaring weakness: If an attacker captures the initial key exchange and later gets the private key in some way, the can decrypt the previously captured traffic.
Cipher suites which support forward secrecy work in a different way. Instead of transmitting the secret over the wire, a key exchange protocol like Diffie-Hellman is used, in which the actual secret to be used is generated through mathematical means. I'll leave it up to the reader to see how it works exactly. The advantage is that the secret is ephemeral, meaning that it exists only for one session and that's it. Even with access to the private key and the entire communication, the secret cannot be determined. Furthermore, if the secret key used in one session is compromised, other sessions are still secure.
So what does this all mean?
In simple terms: Don't use cipher suites that Qualis SSL scan claims to be weak. You have no advantages in doing so.


Does an Egghunter attack still make sense in a 64 bit system?

It can make sense, but you have to rely on luck. So simply put, it can work but it's not really reliable. You don't have to search through the whole adress space, as only the user-space is relevant (47 bits). If you want an in-depth explanation, this article experiments with this attack on a 64bit system.
https://pentesterslife.blog/2017/11/24/x64-egg-hunting-in-linux-systems/


Fuzzing and its impact on testing environment

Any testing, not just fuzzing, should be performed in some sort of sandbox (eg. a virtual machine).  This has two main benefits: 1) you can quickly reset things to a known configuration, and 2) bugs (such as a runaway recursive deletion that includes .. in the list of directories) can't harm important data.


How is no password more secure than username+password?

They have configured the laptops to spin up a VPN connection and only speak to "home base" after they go on the network.  That means that if there is a local "captive portal" that requires you to enter credentials, you will not be able to use it, because that would require evading the VPN.

(It's a chicken and egg thing.  No VPN, no ability to reach the portal - no portal, no ability to spin up the VPN!)

It is more secure because they are ensuring that, no matter what connection you have, any network traffic you send goes through your company's network, your company's controls, and is not subject to interception or manipulation by any other party.

It unfortunately breaks the case of Wireless with a "captive portal," but allowing for that case would lower their security by allowing your machine to talk to arbitrary machines directly rather than through the VPN.

The "eduroam" service that you mention in the comment explicitly  states that they do not have a captive portal, but use WPA-Enterprise based on 802.1X:

  Does eduroam use a web portal for authentication?

  No. Web Portal, Captive Portal or Splash-Screen based authentication
  mechanisms are not a secure way of accepting eduroam credentials....
  eduroam requires the use of 802.1X...

802.1X is the kind of authentication you need to enter to configure your machine to connect to the network, so this case is one that your IT policy explicitly states that they allow:

  if it’s set up so that you need a password to connect to the WiFi (and
  this password is given to you by the establishment) then again, you
  should be OK

In fact, eduroam appears to be very well aligned with your IT policy - they both distrust the "bad security" imposed by captive portals.

Based on the edit to the original question:

  I am trying to connect to eduroam, but I cannot do it using my
  organisation's laptop. When I use a personal computer, it asks me for
  a username and password, just as a standard wifi network asks for
  password.

That suggests to me that your organization's laptop is simply not prompting you to connect to new networks the same way that your personal computer is.  This could be because of different operating systems or different policies applied to the two computers.  You may simply want to ask your IT group for help configuring 802.1X for connection to the eduroam network; using that keyword will make it clear to them you're trying to do something they allow.


Most secure way to store a cryptographic key for encrypting/decrypting stored application data

I will not give a direct answer here, because it can depend on the context.
First, if the application must run in an inattended way, for example automatically restart if the server reboots, there will be no truely secure way to store the primary key. So you have 3 options here:

most secure: require a human action to enter a password when the application is started. You can securely store the main key in an encrypted container, but you need a password owner each time the application is restarted.

standard: store the key in an unencrypted container in a file accessible only to the application or to the administrators

median: use obfuscation. The main key is mangled before being stored and will be demangled by the application before use. Any bijective operation can be used for mangling.

The fact is that obfuscation is not security, because if an attacker manages to find the key, it will probably be able to find the mangling in the application source or code. But it can give you some more time to detect the attack. You must just be aware that it does not add any security by itself, and because of that is seldom (if any) used in large datacenters.


Relatively secure faster alternative for HTTPS

HTTPS is HTTP over TLS.

If you implement a game, using HTTP is usually not a good idea. The HTTP protocol is designed for requesting documents, not for real-time games. A better idea would be to develop your own protocol directly based on TCP or UDP (UDP is faster while TCP is easier to use, but that's a topic for game development stackexchange) and tunnel it through TLS.

The time-consuming key exchange process only needs to happen once when establishing the connection. When you keep the same connection open during the game, the only latency overhead is caused by encryption and decryption. TLS supports multiple cipher suites (sets of cryptographic algorithms which are used). The choice of cipher suite can be used to find a compromise between performance and security.


The problem with SSDs or other encrypted drives, is side channels attacks are ONLY possible while the device is operating with the key. You need to monitor it doing active encryptions/decryptions WITH the real key.

95% of people wanting to break SSDs have them sitting on the table, without the key. So your "classic" side channel attacks aren't relevant (since if the key is encrypted with another key correctly derived from a password, the drive sitting on the table does not know the real decryption key).

The AES engines in most drives won't be SCA resistant (I imagine), so it's probably possible to do an attack. But again it's only possible to do so while the drive is operating under normal conditions. They could be useful (SCA on a laptop sitting on a desk, you can put a sensor right under the drive?), but I think if you have the ability to get that close to the target computer there is normally better (easier) attacks.


Using HTTP Basic Auth on a Personal Website

If your the only person accessing the website then it's only network you access the website need to be secure. For example, let's say you only operate this blog from your home network. If your home network was compromised by an hacker and they was ARP spoofing on network to capture your credentials or had control over your router to log packets.

I'd recommend you also (if you're not already doing so) is hash your password client side using javascript / jQuery before sending it accross the network. You could also throw an handshake on there to make it harder to compromise too.

If you want to go for a step futher on tighting up the security:

Client request login page
Server gives them login page with handshake key
Client hashes the password and does password then appends handshake key and hashes that.
Server get password from DB which is hashed and handshake key and ensure that is valid before processing it. Ensure the handshake key isn't managed by the client.
If handshake passwords, compare password to DB password.

This would prevent hacker if someone compromised the local network and got your hashed password they wouldn't able to login to your account since they wouldn't know the password for the handshake.


Is it possible for a website to get information about you through its upload feature?

No.

A browser does not leak information apart from the selected file(s) and the information that can be accessed using JavaScript WebRTC etc. anyways when using the HTML file upload input.
There might be some calculations going on in the background like calculating CRC's until you're able to submit the form.


What's going on in this visual render of an attacker and defender in Information Security?

This is a DDoS attack.

The purple bubbles are infected computers. By having thousands of infected computers, an hacker can simply force them to attack a target. This kind of attack means that there will be so many requests to a single server that he cannot handle with them all, making the server crash or simple not responding for a while.

To understand what is the definition of a DDoS attack i just copy a simple definition from wikipedia

  In computing, a denial-of-service (DoS) attack is an attempt to make a machine or network resource unavailable to its intended users, such as to temporarily or indefinitely interrupt or suspend services of a host connected to the Internet. A distributed denial-of-service (DDoS) is where the attack source is more than one–and often thousands of-unique IP addresses.

The green bubbles are honeypots. The honeypot is just a simple "system" on the network that will provide some distraction to the hacker.

This means that instead of attacking the correct target, for example an webserver, the hacker will be attacking an honeypot, meaning that the real server don't have to handle with all the requests and the attack will not have any real impact.

The red and grey bubles, i think, that are really server responses.


Testing my network using aircrack-ng not working

This is a kernel related issue and I have long wondered why it continues to be so. Ubuntu even removed aircrack-ng from their repositories. Anyway, there are kernel patches on the aircrack-ng website, or alternatively, you could create a bootable USB/DVD drive of backtrack-linux and use that. It's a pretty stupid problem, and I wish I could tell you why, but can only guess. And my guess would be cynical.

Specifically, the channel will not hold to that of the AP, no matter how many times you set it with iwconfig, airmon-ng, etc. Very annoying! Many probably think it is their wireless chip at first, but even the legendary rtl8187 suffers.

Also, the aircrack-ng forums do extensively cover this known issue, albeit in their own lingo. They generally don't respond to questions when what they consider answers exist on their forums. Admittedly, the solutions are not always perfectly clear.


can an attacker find WPA2 passphrase given WPA key data and WPA MIC

WPA2 has three main key types:

Pairwise Master Key (PMK) - the shared passphrase
Pairwise Transient Key (PTK) - a key used for securing communications with individual clients
Group Temporal Key (GTK) - a key used for securing multicast traffic

The PTK is generated from the following data:

Shared passphrase (PMK)
A nonce value generated by the access point (ANonce)
A nonce value generated by the client station (SNonce)
Access point MAC address
Client station MAC address

The SNonce value has its authenticity and integrity provided by a Message Integrity Code (MIC). Strictly speaking this should be called the MAIC, because it provides authenticity as well as integrity.

The above values (excluding the MIC) are concatenated and put through PBKDF2-SHA1, in order to generate the PTK. After this, the AP sends the GTK (and a corresponding MIC) to the client. The PTK and GTK are then used as the encryption keys for further transmissions, for unicast and multicast respectively.

The overall handshake looks like this:

If the attacker captures the PTK, ANonce, SNonce, AP MAC and client MAC values via network sniffing, he can then brute-force the PMK. The MICs do not need to be known, because they does not contribute the PTK value.

Since PBKDF2 is a slow key derivation algorithm, a normal bruteforce would be rather inefficient. A dictionary attack is much more feasible.

Further reading:

WPA2 on Wikipedia
TKIP on Wikipedia
Enhanced TKIP Attacks (PDF)


You would simply set $file_name to passwd.csv and file_path to /etc/passwd.


Why do some people think linux machine accounts with passwords are more secure than accounts without passwords?

It really depends on what you call password less accounts. An account with an empty password in the password database (normally /etc/shadow) is highly unsecure because anybody could use it. On the other hand, an impossible to match password like * in same database prevents anybody to log with this account because no password could ever give such a hash. In the latter case, adding a password is just useless and actually lowers the account security because it could be brute forced.


Exploiting a PHP server with a .jpg file upload

Regardless of the placement of the PHP code [...], the website just shows the image file when I open it after uploading

Yes, that is how it should be. The server would be seriously vulnerable if it would interpret .jpg files as .php files depending on the content instead of the extension.

  So in such a case, what should be done to execute the file as .php?

Without some kind of vulnerability in the code itself, you can't execute image files as PHP files, as any decent server would not allow this.

Without knowing more about the code, we can't do more than guess. If it's supposed to be vulnerable on purpose, I would guess that the extension check is probably broken.

You might try:

.htaccess: the extension check may interpret this as no extension, and it may be fine with that. If the server parses the .htaccess file, you can then gain code execution with image files via AddType application/x-httpd-php .jpg.
vuln.jpg.php: the check may check the first, not the last extension.
vuln.php5, vuln.php4, vuln.phtml, etc: the check may be a blacklist check, not a whitelist check, which may miss some extensions which may be interpreted by the server as PHP files. You can easily test this with a madeup extension such as foobar, if it passes, it's a blacklist filter.
LFI: You may have a directory such as misc with subdirectories uploads and configs, where configs contains PHP files, and uploads contains the image uploads. Then you may have code such as include "misc/" . $filename. Lets say that there is a check for directory traversal, so this should be bad code, but generally still somewhat secure, right? Well, included .jpg files are parsed and executed as any other file would be, and thus PHP code inside it will be executed. This example is a bit far fetched, but it's not completely inconceivably that something like this may exist.

tl;dr: You can execute jpg files as PHP files via .htaccess or via include. Additionally, you may be able to bypass the file extension check if it is insecure.


What are the EFAIL "backchannels in email clients not related to HTML"?

At first I would recommend to not only read the homepage of the vulnerability but the actual paper since it has far more details. Your questions are both answered when reading the paper.

  Why is it recommended to completely disable HTML rendering? Would it not be enough to disable loading of remote content (which is the default in most modern mail programs anyway)?

Since the setting to disable remote content (if it exist at all) often does not actually disable all remote content. To take just one example from the paper (page 20,21) the following will cause a request to a remote URL in Thunderbird even though loading of remote content was disabled:

<link href="http://efail.de" rel="preconnect">

  What other backchannels are there which are "not related to HTML"? Did the authors elaborate on this somewhere?

Yes, the authors clearly elaborated about this. At page 20 and 21 of the paper  the authors list the behavior of lots of different mail clients regarding possible backchannels. And while most of the backchannels require HTML some can be caused by normal mail headers. For example according to the paper Apple Mail can be used for a backchannel like this:

Remote-Attachment-Url: http://efail.de


Blind SQL injection: understanding heavy queries

I believe that the intent is to make the query take a long (measurable) period of time should the query be executed in one particular way, and as a result take a short period of time if it were executed another.  This means that you can determine those parts of the query that was executed.

How you interpret that, however, depends on what your original query was, and what you have managed to SQL inject into it, and you are not limited to determing database platforms.

Using blind SQL injection you can turn the database in to a TRUE/FALSE machine where you can ask TRUE/FALSE question about anything stored and get an appropriate reply, and so you can slowly work out a great many things about the database.

Real life example  I had an case of blind SQL injection that would take a long time (about 20 seconds) if some injected query were true, and would return immediately if false. So given the injection string:

value' and 'bob' = (select user from table)--

I can enumerate all the users of the system


Can security devices (e.g. Snort, Splunk, WAFs, etc.) generate alerts when they aren't working as designed?

None of these security devices you have listed have subsystems that can report on the integrity or availability of themselves. You will need to use an external piece of software to monitor your security devices.


Can I decrypt a .gpg file by using Windows CNG store/ProtectedData?

I've solved the issue by calling gpg.exe with arguments, which automatically chooses the correct key from the keyring.


What are the tradeoffs in cost, effort, and value in moving a database server to a virtualized DMZ environment?

Is there any reason you wouldn't just NAT connections from the gateway to the internal DB server rather than completely moving the box to the DMZ?

As for the issues you list, I wouldn't worry too much about #3, because no matter what your DB server needs to be properly secured.  The only way to really mitigate that risk is have your development box make calls to an API that handles communication with an internal or otherwise unexposed DB box.  That way you don't have to totally open the floodgates to the DB server.

It sounds like you may have other data unrelated to the development tool on this DB server as well, which makes moving it and managing the risk undesirable.

Bleh, making these decisions is never fun, but ultimately that's our jobs, right?

If using NAT to handle the routing isn't sounding too good to you, and setting up API access to the DB isn't feasible either; you've got to take a good hard look at what this DB server is up to and go from there.

The entire purpose of a DMZ is to expose necessary services to the outside world while protecting internal operations as much as possible.  Meaning, just because I need DB access doesn't mean I need to be able to ping every machine and printer in the office.  That said, if you've got data on that DB server that has no business being accessible from the greater internet then that server absolutely does not belong in the DMZ and you should really setup a new DB server to house that data which does need to be accessed from the greater internet.  That's exactly the purpose of the DMZ.

As for the data redundancy bit, I do not believe this situation warrants having two servers with the same data replicating to each other with internal users hitting one and external users hitting another, that's almost always a terrible architecture.  If this DB instance ends up in your DMZ you'll have to setup routing and/or use internal DNS to ensure local traffic gets to the box in the DMZ.

Left Field: Rereading your question I'm wondering if there isn't another solution hiding here to get at your real issue which seems to be latency and availability of delivered data... if you've got files that need to be delivered publicly with low latency is there any reason you aren't storing them on some third party storage like s3 or cloudfront CDN?

The approach would essential be storing all the information about the file on the DB, generating some hash for a given file name (you mentioned videos?) and storing a link to S3 or the CDN in the DB.  If the only reason you're thinking of moving the DB is to control latency on data blobs that get sent to a user I think you're better off rethinking the problem rather than coming at this as a question of data "access" which is ultimately what the DMZ is all about.


Your scheme looks just like a JSON-serialized client-side certificate with all the usual bells and whistles - it includes issuer, subject, validity period, and usage.

To securely use authentication tokens, one must meet at least the following 4 requirements.

The token is cryptographically unforgeable (by any reasonable adversary).
The authentication server (authentication source) must correctly implement access control(s).
The service hosts are honest.
The token cannot be reused past certain reasonable amount of time.

The part I suggest look into would be defence against dishonest servers. Possible attacks include man-in-the-middle data capturing and modification. This should be the responsibility of the client who must verify the authenticity of the servers.


How to prevent emails where sender has been spoofed?

Is there any way to prevent this?

Yes and no. You can't prevent email from being spoofed. But you can use electronically signed emails, and you can advise the IT staff to start using DKIM or similar, to prevent such emails from being accepted. After that:

a non-DKIM or non-signed email will be considered a forgery and rejected.
users will need to send emails through the organization's servers and/or sign them digitally with their private key.
users will need to only check the company email through the company server (no simply forwarding to convenient GMail accounts readable from the cell phone. You can still do that, of course; it just gets more complicated).

  Is there any way to report this given that it comes from the great internets?

Not really. You can try checking the headers and report them to the appropriate abuse office (i.e. that of the originating domain). Most such emails come from either zombied individual systems (maybe operating in groups - so-called bot nets) and/or domains and organizations that have been found to be either unresponsive or straight away friendly to forgers and spammers. There are actually lists of "promising pasture" networks circulating that allow abusers to find new victims.

  What security precautions (apart from please check emails carefully before replying) can I advise the finance and other teams?

Other people (the IT team) should implement what precautions can be taken, and the necessary infrastructure (for example, if lots of employees need to send emails while on the go, they might need to be equipped with VPN software so that they can securely use the organizational infrastructure even while on insecure grounds such as an Internet café somewhere). The other people should need do nothing except, as you suggested, carefully double check; and of course use properly whatever infrastructure they've been equipped with.

So, for example, if you do have a secure mail server, you need to go through the bother of actually firing up the VPN connection, authenticating, and sending the email, rather than just shooting an email from the hip from some unsecured hotel room WiFi.

That's particularly important for "weighty" individuals which, in my experience, often are tempted to consider themselves above the law, and will insist on having their emails read and immediately acted upon whatever the source, as they "haven't the time" of jumping through the various IT hoops (they are right up to a point: the security infrastructure must be as easy to use as possible, or it will be seen as a burden, will be routinely worked around, and thereby made useless).

One thing to carefully consider is how the various users connect now to the organizational infrastructure. In-house employees are obviously the easiest. But some OSes and cell phones, for example, cannot use certain security measures. So you either replace those devices, make do without those measures, or resign to some users being cut off from the network in certain circumstances.

In a pinch, you might need to set up some emergency procedure should the CEO ever find himself really stranded in Elbonia with no luggage, no documents, and need money to be sent over to catch a flight back home.


Is it possible to predict Python's random.random() if it is constantly seeded with high entropy values?

If you reseed it after every time you draw a number, it will be as safe as whatever you reseed it with. Think of it like this. Your seed source generates a series of numbers xi. You run these through Pythons random number generator, essentialy generating a new series of numbers f(xi). Given that f doesen't scew the distribution (and a random number generator shouldn't), you will just have applied a pretty pointless transform.

This doesn't mean that what you are doing is a good idea. It  looks like an ugly hack to me. Ugly hacks introduces complexities that can lead to mistakes that can lead to vulnerabilities. If I were you, I would just write my own securePick method and use that. It shouldn't take many lines of code.


Well if your system has a private ip and is behind a router (using ipv4,nat and firewall).
Considering you are also not running a natted server.

You may be considered a bit safe from my opinion , though other attacks (like after packet manipulation may be possible,etc)
Than it would depend how much securily your router is configured.

At last you can check for vulnerablities for older packages (Openssh,Openssl) ,also for your linux-version from sites like cvedetails.com.
Apply patches or upgrade your package according to your necessity.


Is there a password based challenge response authentication scheme with public key cryptography?

What you're talking about is a zero-knowledge proof (or more specifically a ZKPP) similar to RSA-PAKE.

If we ignore the general problems of implementing RSA safely, there are a few problems with the scheme you suggested:

Since an attacker viewing the key-exchange knows c, if the value of ch is ever less than n then r = ch mod n = ch. From this the attacker would recover ch, and could compute logc(ch) to recover h and crack it offline.
The server is never authenticated, so an attacker could presumably select a value of c that is advantageous for the above attack, or other attacks.
You can't just use the raw result of a hash function to select e, because e must be relatively prime to φ(n). So you'd need to do some manipulation to ensure that e is a safe value. You'd need to ensure that this manipulation doesn't weaken the safety of the hash excessively.
The server must validate the initial setup values sent by the client, otherwise the whole scheme may be broken due to incorrect key generation or manipulation. This is difficult to do while maintaining zero-knowledge.
There are some potential attacks around schemes where an attacker can select the value of e interactively, such as e-residue attacks.
You'd need to be careful about error side-channels and timing side-channels on some of these operations.

What you probably want to look at is a protocol like SRP, which handles ZKPP authentication while avoiding most of these problems.


It is indeed too large of a keyspace. ?a is 95 characters. 95^14 is 4x10^27, which won't be exhausted any time soon.

If you want to reduce the possible characters as you describe, use a custom character set:

hashcat -1 '?l?d!_-,.:;/' ?1?1?1?1?1?1?1?1?1?1?1?1?1?1

But even this keyspace 44^14, or 1x10^23 - too large to reasonably exhaust.

Unless you can narrow down your keyspace further, brute force won't help you here.


ownCloud on an encrypted partition on the server

My question is if I can securely encrypt the /var/www directory in a way that the service provider cannot (easily) access my files (so I'll have to manually enter a password at every VPS reboot to mount /var/www). I assume that I cannot (easily) modify the existing partitions because I cannot umount them.

No, because when your server software can decrypt it, the key must be in RAM, and since the RAM is just virtualized, your VPS hoster can access it trivially.

You can, however, encrypt the data on your clients and just upload the encrypted data. That's the proper way of storing data on other people's computers. (Remember, there's no cloud, just other people's computers.)


From what I understand using GET to submit usernames/passwords is a security issue because the username/password are part of the URL which can show up in browser history.

That's not the only issue. Using GET for situations where the user is submitting data opens up your application to CSRF vulnerabilities.

For example, I could embed <img src="http://yoursite.com/login?username=something&password=somethingelse">, which may log visitors on my site out of your site due to the call to the login handler. This specific example depends on implementation, but other attacks can be made. There may be cases when an attacker wants users to be logged in to their account.

Besides that, other loggers on the way (your ISP, etc) may log this for a longish period of time. Of course, the same can be said about POST request, but usually the full request dtails won't be kept for long.


What are the technical implementation differences between signature-based scanning and heuristic-based scanning?

Heuristic scanner (for a file) can look/do for various things, including:

sandboxing the application and analyse the behaviour (which files are created/deleled/modified, ...)
looking for hooks to functions (direct disk writing, TCP socket binding, ...)
strings like filenames (read/write of system files, ...)
memory residence ability
decryption of the program at launch
decompiled machine code analysis

The detection of one or multiple of these elements can point toward a possible threat. A program which is resident and modifies the hosts file, is very likely to be ill-intended.

As for network based analysis, I am not very familiar of it. But I'd say, if there is a machine dedicated to this, it would be possible to run analysis of captured file and/or reported files.

(possible interest in Rethinking Antivirus: Executable Analysis in the Network Cloud)


Badlock was massively overhyped and, it turns out, the  name has nothing at all to do with the vulnerability (it has nothing to do with bad locking, mutexes, or anything of the sort). It requires a man-in-the-middle attack to carry out, and allows an attacker to execute arbitrary Samba network calls using the context of the intercepted user. The attacker will gain read and write access to the SAM database and will have access to password hashes, which they can use to elevate privileges.

The vulnerability is CVE-2016-2118. According to its description page:

  The MS-SAMR and MS-LSAD protocol implementations in Samba 3.x and 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 mishandle DCERPC connections, which allows man-in-the-middle attackers to perform protocol-downgrade attacks and impersonate users by modifying the client-server data stream, aka "BADLOCK."


How can IA-5(1)(b) be enforced on Windows systems?

Believe the only way is to write your own custom password filter.

There are also plenty of third party products that will do this for you e.g.

http://nfrontsecurity.com/products/nfront-password-filter/
http://www.anixis.com/products/ppe/default.htm

Even Windows 2008 password complexity will only check:

Passwords cannot contain the user’s account name or parts of the user’s full name that exceed two consecutive characters.
Passwords must be at least six characters in length.
Passwords must contain characters from three of the following four categories:

English uppercase characters (A through Z).
English lowercase characters (a through z).
Base 10 digits (0 through 9).
Non-alphabetic characters (for example, !, $, #, %).

http://technet.microsoft.com/en-us/library/cc264456.aspx

This default complexity check with user education and providing a password manager is sufficient for most companies to mitigate the risk.

If you are really worried about someone setting ChelseaFC01, ChelseaFC02, ChelseaFC03 and this being guess through social engineering i.e. attacker finds out user likes Chelsea and cycles through this combination you could move away from just relying on password: e.g. implement two factor, adaptive authentication etc. You could also monitor for multiple password failures e.g. 8 attempts then a success via the Active Directory logs and investigate these.


Are PPM or BMP images safer than JPEGs or PNGs?

The question is: what makes a PPM file safer? Is it because there's no room to hide a payload, without becoming too noticeable at first sight?

No. You might argue that for plain text files (not strictly true, but that would allow to vet most of them).
However, for most images, you wouldn't be able to discern the payload from the image data.

Or is it because the format is so simple to parse, that we can suppose our software will be less likely to be vulnerable, when opening such files? And most importantly, is it even true that we can consider PPM files (and maybe also BMP) to be safer than, say, more complex formats like JPEG or PNG?

Exactly. Decompression routines are complex. Code rendering formats like JPEG or PNG have an higher chance of having a vulnerability on there. Still very unlikely, albeit there were a few of them (e.g. JPEG 2000 one years back), but it is higher than for a dumber format.


Web application penetration testing methodology

There's a chance that the result of exploiting a vulnerability early in the test could change the application. Either crashing it or just breaking certain functionality. Thus making the need to scan for additional vulnerabilities moot.

Another reason for thoroughly identifying vulnerabilities is to give the person performing the test a full understanding of the application. Perhaps that first vulnerability could be exploited even further with information gained in the later stages of the vulnerability assessment.


Having tested this at scale with a wide variety of browsers there does not seem to be any issue with the reporting endpoint being on a different domain.


Runtime checksum of Mach-O differs from executable checksum

This is because of the dynamic linker, dyld.

Certain sections of the __TEXT segment, such as __stubs get modified in memory by dyld so as to be able to call out to the linked symbols. Basically it is dynamically inserting the correct memory address for your externally linked functions like printf and sprintf.

Incidentally, this whole setup sounds rather silly, as code-signing already does this and more. So long as they are modifying the code, they will might as well modify your additional integrity checks too. It's hard to believe you won't end up spending more of your time on this than a half-way decent hacker will spend defeating it.


Is multi-factor authentication supported by any current bios?

It's difficult to say, since there could be a BIOS somewhere that does it, but I've not been able to find anything. You're probably going to have to stick to password protecting your BIOS.

If you're looking for a way to secure your system with multi-factor authentication, consider setting up TrueCrypt and using system (boot) encryption to encrypt the entire disk. This allows you to set a password to decrypt the disk at boot, and (if I remember correctly) you can use keyfiles off any standard USB mass storage device in newer versions.


With the server must store a "password verifier" with a special structure; in SRP 3 (the one described in RFC 2945), this is described this way:

The host stores user passwords as triplets of the form

    { <username>, <password verifier>, <salt> }

Password entries are generated as follows:

    <salt> = random()
    x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
    <password verifier> = v = g^x % N

The protocol cannot work if the server does not have v or the salt because the server must send the salt to the client (in the initial steps of the protocol) and must use v not long afterwards. Therefore, regardless of what the server actually stores, the server must know enough to retrieve or recompute the salt and v in a fraction of a second. An attacker who obtains a complete copy of the server will be able to do the same, and get to the salt and v, allowing for a fast brute force attack on the password (fast because the computation of v, given the salt, username and a putative password, implies only a couple SHA-1 and a modular exponentiation).

So the only hope is to find a way for attackers to not obtain a complete copy of the server. Namely, symmetrically encrypt the data which is stored, with a key which you will then store "elsewhere", and pray for the best. For instance, most breaches of the "SQL injection" persuasion allow for the attacker to grab a more or less full copy of the server data as stored in the database, but does not (immediately) allow for reading arbitrary files outside of the database. If the server stores the symmetric encryption key in a file, and use that key to encrypt the relevant fields in the database (namely, the v values), then attackers who only get a dump of the database will be defeated.

A variant is to setup an extra internal server who stores the salt and v values. Your main server would talk to that secondary server. It would then be up to that secondary server to detect attempts at exhaustive pumping of all values, should the main server be totally hijacked by attackers. At least, the physical separation would protect the sensitive values (salt and v) from SQL injections and similar breaches.

There is little more you can do without modifying the client.


Parallel HTTPS connection remote and local host

Due to the same-origin policy,  JavaScript running on a remote site cannot use an XHR to access content running on another domain.  Cross-Origin Resource Sharing (CORS) is one solution to this problem.

The server running on localhost, can define a CORS header which permits JavaScript running on a specific domain access to the server.


ISO14443 is just a link protocol like Ethernet, as far as I know it does not provide any security by itself, it's up to the different vendors to implement their own on top of that.


EME doesn't "allow" proprietary code, that's a misinformation of Wikipedia based on this four years old post , a post which does not provide real information, just the assumption that at some point a full DRM solution will be integrated into the browser.

The EME is just an API to interact with the license server and the Content Decryption Module. This CDM is the one responsible for decrypting the video. It runs in a sandboxed environment, so no access to your computer is needed.

The whole purpose of EME is to not need a plugin to use a DRM system, so you don't need to rely on third party plugins (Flash, Silverlight...). Therefore, you are removing an often vulnerable point.

In summary, the EME doesn't add any security at all from the server side, but it provides security in the client side removing the need of installing a third-party plugin.


Preventing Browser from BeEF Exploitation

There are Yara rules submitted by SANS ISC to detect BeEF, and these could be repurposed by yarashop for the network layer as a early-warning detection system. The author shows how to utilize Volatility to read into a memory capture and look for BeEF-related signatures and communications -- https://isc.sans.edu/diary/When+Hunting+BeEF%2C+Yara+rules+%28Part+2%29/20505

In order to remove a Javascript hook, such as BeEF, you would typically only need to clear reopening pages/tabs, history, and cache before restarting all browser processes. However, in some persistent BeEF scenarios, you will also need to consider other offline browser stores, such as HTML5 offline cache.

You are right to want to look for BeEF, but you will also want to dig a little deeper. It is easy to obfuscate Javascript and can be difficult to modify your detectors to catch these obfuscations. Other Javascript-hooking packages, such as XSSF, Scanbox.js, or the metasploit-framework's auxiliary/gather/browser_info module can be utilized instead of BeEF.

Emerging Threats, recently acquired by Proofpoint, has a set of Snort rules -- https://rules.emergingthreats.net/open/snort-2.9.0/rules/ -- many of which cover BeEF, XSS, Scanbox, et al. You will especially want to check out the emerging-trojan.rules and emerging-web_client.rules files. There are specific entries for BeEF and Scanbox, as well as generic ones to catch active XSS from the client (i.e., browser) perspective.

Here are two articles that discuss how threat communitiies are converging on these Javascript-hooking technologies -- https://www.helpnetsecurity.com/2016/04/28/attackers-use-open-source/
-- http://www.securityweek.com/attackers-increasingly-abuse-open-source-security-tools


What are the functional similarities and differences between TPM and SGX in trusted computing?

Well first off, SGX is not a crypto chip. It is a feature built into Intel chipsets themselves, whereas the TPM is often a discrete chip positioned on the LPC bus, though sometimes it can be emulated in the chipset (in which case it's called fTPM, for firmware TPM, or iTPM, for integrated TPM). On Intel processors, an integrated TPM will be present for any system that supports TXT.
Trusted Platform Module (TPM)
The TPM is designed to allow for measured boot, a boot process where each stage verifies the next stage in a chain of trust, reducing the Trusted Computing Base (TCB) to a much smaller amount of code. The way it works is by getting a hash of various firmware-related data and storing it in PCRs (registers in the TPM) and unsealing a secret value if this matches a known configuration. This all starts with the trusted CRTM (Core Root-of-Trust for Measurement), which is a, usually, read-only component of the BIOS that sends a hash of the BIOS itself to the TPM. If the CRTM and TPM are trusted, then the rest of the system need not be trusted.
A TPM cannot act on any detected integrity violations. It is entirely passive, existing only on the LPC bus. All it can do in response to a violation is refuse to unseal itself. This secret value can be something like an encryption key necessary to boot the system, or a secret string not known to attackers, allowing you to verify that the TPM has really unsealed even if it is communicating this to you over an untrusted medium. The TPM also contains an Endorsement Key, or EK, which verifies it as a genuine TPM. Only genuine and approved TPMs will be given this key. This is similar to the PKI infrastructure for HTTPS where a CA allows a browser to verify the legitimacy of the connection to a server.
TPM provides the following guarantees to a sysadmin:

The TPM will resist attempts at tampering (e.g. decapping and glitching attacks).
The sysadmin will be able to verify that the TPM is genuine.
The TPM will only unseal itself when hash values from the boot process are correct.
A key can be set so the TPM will not unseal unless the PCRs are valid and the key is provided.

The TPM is not limited to being unsealed at boot. It can be unsealed at any time. As a verified boot can also verify userspace applications, a TPM can even be used, indirectly, to attest to the fact that a system is running a given piece of software or is configured in a specific way. Once the BIOS, bootloader, and kernel are verified, it can verify that the system is in an arbitrary state, for example, has up to date software. Only when all of this is in a valid state will the TPM unseal itself, allowing it to prove to clients that it is running up to date and secure software. This is called remote attestation, which itself can be used as a building block for network access controls.
Note that this is a bit of a simplification of a TPM's functionality, and it does not go into the differences between SRTM and DRTM (Static and Dynamic Root-of-Trust for Measurement, respectively), but it should be sufficient for the purpose of describing the general functionality of the system.
Software Guard Extensions (SGX)
SGX has a different design goal and is a good bit more complex. SGX can provide confidentiality and integrity to processes, and can verify the executable code before executing it. It is an active feature, and encrypts processes running in a secure enclave while protecting them. The processes know that the enclave is genuine, preventing it from being spoofed via emulation, and the enclave knows that the process is genuine, preventing the untrusted host from giving it a compromised process.
The secure enclave cannot even be read by the kernel or any other privileged task once it is set up. Because of this, a process running in a secure enclave can, at worst, be killed or made to crash. It cannot be tampered with (even with JTAG, as probe mode is disabled in SGX context, or so I'm told). This can be used for things like running a virtual machine guest which does not need to trust the host.
SGX provides the following guarantees to a process running in a secure enclave:

The process will be able to verify that it is running on genuine SGX.
The host cannot tamper with the process once it is running in the enclave.
The process gets to define an I/O API for communicating with processes on the host.
The process' state will never exist in plaintext in memory.
The process will be verified before being run, ensuring that it is legitimate.

Typically, an application making use of SGX would have to be designed specifically for this purpose. The application would be written to have two components. The first component would run unconfined on the host, whereas the second would be run in a secure enclave. An I/O API is defined for allowing the two components to communicate with each other. Any sensitive computation can be offloaded to the process in the secure enclave.
While SGX protects the enclave from the host, it does not do much to protect the host from the enclave. A malicious or compromised enclave process could exit the enclave and execute arbitrary code on the host. This is due to the fact that the EEXIT instruction (see page 67), which exits the enclave, only restores a limited number of registers. In particular, it allows the enclave process to set RIP, the instruction pointer, and jump to an arbitrary address.
Similarities
The TPM merely tells you if your firmware or boot process has changed, and nothing more, whereas SGX is instead used to protect sensitive or confidential processes from the host. One similarity TPM and SGX have is that they both cannot be spoofed, allowing a system to know that it is talking to the real deal. Another is that they are both involved in the concept of trusted computing, reducing a system's TCB in various ways. Both systems have their own set of flaws. TPM version 1.1 and prior is vulnerable to the platform reset attack, for example. SGX is vulnerable to side-channel attacks, as two papers have recently shown.
Other than that, they are quite different, and they solve entirely different problems.


Can we tamper-proof a game that's sold along with the Windows machine it runs on?

We can analyze your setup by comparing it against a system known to be not tamper proof, the Sony PlayStation 3.

OS control

You have no control over the OS. Sony did write the OS themselves.

Size of the OS

The PS3 OS can be very simple as it just needs to boot games. Windows is a generic OS, with many, many functions. This exposes many API's.

Shell

The PS3 OS shell is intended to just start games. On Windows, the default UI is provided by Explorer. You propose to replace it, which isn't a design goal for Microsoft. It may appear to work, but tearing out Explorer may leave some open interfaces. That is a special problem for you because such open interfaces may become attack vectors.

Hardware

You appear to be working of a standard PC hardware, just with TPM. Sony had designed the PS3 from the start in the assumption that hackers would be attacking the hardware.

Your standard PC probably has PCI-e slots. Those support DMA. Using that, you gain access to the PC's memory. This will be unencrypted. A common way to do this is via FireWire. IIRC, modern consoles now keep the RAM encrypted as well, and they obviously don't grant DMA access to outside hardware.

Conclusion

Your system appears less safe than a PS3, and a PS3 can be hacked, so it is safe to assume yours can be too.


Friendly reminders for people who don't lock laptops

Those cards will be seen as punitive no matter how well you phrase them.

There's another way: cards for those who locked their machines!

Punishing behavior you don't want won't always mean that you will get what you do want. You might just get less of that undesired behavior (e.g. people hiding their unlocked machines or other such nonsense).

But if you reward the behavior you want then you will see more of that behavior.

Just a simple card will do, and I'd toss in a small candy or some other small reward.

Say "Thank you!", not "Ya done screwed up!"


Clicking web page taking me to adware/malware!

I would suggest to look into your network configuration. That sounds like someon is intercepting your traffic. Maybe your DNS entry was changed by another user of the wifi. Check this by going into your router configuration and look if your DNS Server isn't the router or your hosting Provider. If you are not sure what´s your DNS name use 8.8.8.8 for testing purposes. This is the google DNS server

It seems that another PC or device routes you to this sites. Is the same behavior on https sites or are you always routed to http?


Extracting packets from a network without being directly connected to it?

No. What you describe is not a weakness and also the channels don't matter in terms of security. With airodump-ng you can immediately see all access points in your proximity and also the devices connected to them. This requires absolutely no technical skills (I might be wrong. Some people don't manage to set their network device into promiscous mode ;-)). The point is simply that on OSI layer 2 (802.11) the header information is not encrypted so you can easily see which MAC address belongs to which AP. This is not a matter of concern. I believe using the same channel as another AP in your environment might affect the availability or reliability of your network, but security is not a problem.


The difference between the two keys is that the Master key (PMK) is supposed to be valid for at least as long as the client is connected. In the case of WPA-PSK, the PMK is the same from the moment the AP is configured until either the passphrase or the SSID changes. Therefore, if the PMK is compromised in any way, the attacker gains "permanent" access to the network.

To protect the PMK, the protocol derives a pair of Transient keys (PTK and GTK) that are used to directly encrypt communications. These may be expired and renegotiated several times in the course of the client's connection, and the compromise of either of them does not gain the attacker permanent access to the network. The next time the client connects, it will generate a new pair of Transient keys from random values generated on the AP and the client, combined with the PMK.


Here are a couple exploits for remote heap overflows for some older Linux daemons.

Unauthenticated remote root vulnerability in Samba 3.x - This describes the module for the setinfopolicy_heap exploit, which is included by default in metasploit.
Remote heap overflow in OpenSSL < 0.9.6d - A fairly advanced exploit for its time (2002). Includes detailed information on the vulnerability and exploit development process, along with a tarball containing C source for the exploit. Not metasploit, but just as easy to use.

Both of these will work for your demonstration, and could be easily setup by compiling older versions from source, or installing older RedHat/Debian ISO's in a VM.


I'm scared if my school can see what I'm searching

Everyone makes mistakes.
You accidentally clicked on a website. That cannot be helped.
How they could, or would do it is up to them, some maybe just ignoring it (I don't know) some others maybe very strictly and carefully looking trough everything. But I don't think you are in any danger, just because of a accidental click on a URL.
It would be totally different if you browsed that website(continued to browse it, still - realizing it might be against the rules of your school, and tried to hide that fact


How does replacing/overwriting data work in Bell-LaPadula?

No write-down means you can't perform any action to make changes to a system below your authorization level. The purpose is to prevent higher authorized entities from intentionally or unintentionally leaving classified data in an inappropriate location. Applied properly, this should mean that appends, overwrites, new files, etc. cannot be written/created/appended/edited in any way.


Can I get SSL certificates for my OpenPGP key?

How can I use letsencrypt to get a signed public key for use with OpenPGP?

This is not possible for several reasons.

letsencrypt does not Verify Idenitity

  So I can prove in court the key is mine [...]

letsencrypt only verifies domain ownership, with other words whether you have control over the domain. They do not verify any personal information.

Server and Client Certificates

OpenPGP does not really know the concept of server certificates, at least not in a standardized way. At the same time, letsencrypt only issues server certificates. They cannot validate user IDs.

X.509 and OpenPGP are not Compatible

letsencrypt issues X.509 certificates, as used for HTTPs. While both make use of the same cryptographic algorithms, neither the X.509 key format is comptaible with the OpenPGP key format, nor are their signatures (certifications). The problem already starts with how the entities identifying keys (in both cases: fingerprints) are calculated.

While it is well possible to extract the RSA keys (with other words, the numbers used as input for the algorithms), the same RSA keys would have different incompatible representations and formats.

Trust Systems and Certification Authorities

X.509 and OpenPGP have different trust systems. X.509 has a hierarchical approach, with a (some people say too large) set of trusted root certification authorities (recursively) signing both other certification authorities and individuals. The result forms a kind of trust tree.

OpenPGP uses another structure, the more general graph ("web of trust"). There is no central trust instance but your own key, and you have to verify and trust other's keys before. You can somewhat compare this to manually choose, installing and trusting the root certificates into your system's (browser's) trust store before being able to verify any certificates.

  [...] and not have to rely on the OpenPGP web of trust.

You can very well map the hierarchical trust system into OpenPGP, and there indeed are certification authorities in the OpenPGP world: CAcert also signs OpenPGP keys, the German Heise Verlag does so in their "Krypto-Kampagne" (German website), and also in Germany you can get your key signed using the electronic features of the German identity card (German website).

This means still relying on the OpenPGP web of trust, but using certification authorities to "bootstrap trust". For example, everybody trusting CAcert will be able to verify your key based on their signature, without any further "web of trust work" to be performed.


What is the drawback of allowing multiple accounts on a single email?

Password reset, as you've identified. Any type of email notification will not be able to target a specific account.

You could make your site work this way, but it's not a good idea. It's just strange, non-standard functionality. Why require admins to manually reset passwords when users could do it themselves?

What happens if the user forgets which password is for which account? If they request a password reset, how does the admin identify which account to change?

Why does an individual user require multiple accounts? You could investigate the problem they're actually trying to solve, and find a better way to do it.

If it was my project, I would simply tell the client 'no'. Emails must be unique.

It sounds like you're solving one very small (potentially nonexistent) problem by creating lots of new problems.

I could nearly guarantee that eventually your users will ask for an automated password reset utility, or automated account notifications, and you won't be able to provide it.


Difference between "Unknown" and "Hidden" Caller ID

Very good question!
Let me explain:
Hidden:
In every packet being sent to call centers there is a attribute of "hidden" this is a simple flag of true or false and so if the packet has this attribute set to "True" then the caller id will be hidden.
Unknown:
There is an attribute in the packet that holds the origin number that started the call. Since theses packets are editable this attribute is set to an empty number/erased attribute and so the call you are getting is actually from someone who stripped the origin number attribute in one of the two ways.
Note:

Some carriers may attach a random number(Example: 0000000) to the original caller id when attribute is empty/does not exists.
Some carrier may even drop a call with no attribute!
While a number with the hidden flag is still in the packet and is recoverable by the carrier a "unknown" cannot be recovered and so strong spammers prefer to strip the original number attribute.


How to legally blog about Windows internals

Windows is actually quite open about how their operating system constructs work together in the overall system.  In fact there are multiple books written to become familiar with Windows Internals, Windows system programming, and even kernel driver development.  Companies who develop products for Windows need to understand these aspects of the system so it is completely legal for you to learn about these systems.

Windows Internals (Part 1)

Windows Internals (Part 2)

Windows System Programming

A Guide to Kernel Exploitation

After researching and reading on the topic you could then proceed with your blog.  You could also code up your own simple Windows program/DLL, and analyze that within your blog.  You'd be able to use and explore different techniques in a legal manner since you have no EULA with yourself.

That's the approach I would take.


Is there a inherent security threat to having border security receive your passwords?

If you gave me your phone and password for 30 seconds I could install a Remote Access Trojan completely undetectable to the common user that would give me remote access to the phone just like I had it in my hand unlocked (ie. listen to the microphone, access all files, pictures, text messages, calls, ect).  If I can do that I'm sure any government is capable of the same.

So if they did that to your brand new phone, they could access any new information on it as you entered their country.

So yea, I'd consider that a bit of a security issue.


Malware script uploaded - CPU has been maxed out

If you use FTP for access to files on your website, you need to be very careful.

If you store your FTP usernames and passwords on your local computer using software like FileZilla, your website can be compromised if malicious software or a Trojan is installed on your computer.

Never store credentials on your local computer.

Additionally, you should use SFTP (Secure FTP) or SSH (Secure Shell) which uses encryption, instead of FTP - FTP transfers credential and information in plain text. This means that any person or program that is “listening” in on the transmission of credentials to the FTP server, can do so relatively easily and then steal these credentials.

Credentials, such as FTP username and passwords, can be compromised by Trojans and viruses installed on the computers of unsuspecting users “sniff” the credentials being transferred over the Internet to the web server.

SSH (Secure Shell) or SFTP (Secure FTP) will avoid credential compromise from “sniffing” attacks.


How Google Authenticator in Android mobile identifies this is the right SSH server?

Google Authenticator is a offline authenticator. It can both be time-based or event based. Time-based means it will use a Clock to detect the correct code to display.

To prevent desynchronization because the Clocks are imprecise, you simply have a correction factor, so you configure the server to accept a previous code, current code, or a later code.
If a previous code is used, you store "-1" in database. If a later code is used, you store "+1" in a database. And then you decrease or increse the number according to syncronization.
"-1" would then mean you accept the code corresponding to time -2, time -1 and time.
"+2" would then mean you accept the code corresponding to time +1, time +2, and time +3

A important thing is to store the time of the last accepted code, so codes that are equal or previous to the used code cannot be reused.

Since the authenticator is completely time-based, it will mean the same key can be used for unlimited number of servers. Please note that if servers are offline or cannot talk with each other, then a spent code from a machine can be reused at Another machine, provided it hasnt expired in time.

You can also use a Event-based setting, with a counter that Counts up for each display of the code, and then you simply accept all codes that are up to lets say 50 events in future, and then store the Count of the last used code so codes cannot be reused, but then you need one unique key for each machine.

The KeyURI format is to initalize the Google Authenticator, normally you embed the KeyURI in a QR code displayed on screen on account setup, and then you scan it with Google Authenticator to add the seed to Google Authenticator. You simply type a friendly name as "label", for example:
"Server at 192.168.10.3"
And then when you look in Google authenticator, you might see:

542208 (pie of decreasing time)
Server at 192.168.10.3

389578 (pie of decreasing time)
Server at 192.168.10.4

and so on.
Then you know which code you should type in.


Can a router be configured from outside the local network?

According to the manual, if Remote Assistance is enabled, than outsiders can access your router management via the external IP address:

So, it is possible, but is disabled by default, and appears to reset itself to disabled after a reboot.  You should check your configuration as shown to be sure.


Does unsubscribing from an email actually remove my details?

Assuming you are in the EU, then simply unsubscribing from communication will likely not remove any personal information. By law they are still allowed to store any personal information you gave including your email address and it is likely that they are.
If you want your personal information to be forgotten you would have to make a specific request for that to take place under your "right to be forgotten". This is typically done by simply sending a request along those lines to their privacy contact.


Can the Android Snapdragon Vulnerabilities be used to root a phone permanently?

There will propably establish a praxis like:
Downgrade to vulnerable Software -> Execute Exploit / Run Code as root -> Install / Upgrade Software to save level

There is a post in the xda-developers board adressing this technique.


Security on passwords stored by Firefox, against add-ons

It can not read them directly from the manager. It may however obtain it indirectly, for example modify the websites you log into, if it has permission to modify websites. This allow it to for example modify the form to send the password tp them instead of sending it to the legitimate site.
Not to have add-ons you don't need. Use widely used add-ons. Check that permussions of add-ons make sense. Use open source if possible.
If you disable sync, it kind of is possible, though kee pass has additional abilities like allow/deny autofill on case-by-case basis, which FF probably won't ever have. But this is a bit of a moot point as FF is not focused on security to the extent to make it equivalent with KeePass

PS: point 1 is assumeing FF's sandboxing works and has no vulnurabilities, which is most likely not true.


How to properly generate and use (m)TANs?

The most important thing you need is a (good) random number generator. I've seen some cases where TANs where not randomly distributed and so in some kind guessable.

You just generate a list of TANs. The user can select one TAN for each transaction. This is one of the most unsafe variants of using TAN lists. The user can be tricked into some phishing site, enters user name, password and TAN. The attacker take them and uses it.
A better version are indexed TANs (iTAN). Every TAN gets some index number. When the user wants to finish some transaction the site asks for a TAN with a specific index number. When the user visits a phishing site and enters also username, password and TAN it is less likely that he enters the TAN which is needed by the next transaction. So this gives more security.
Mobile TANs (mTAN) is in my opinion the best way for TAN management. If the user wants to finish a transaction, a short message (SMS) is sent by his counterpart. He has to enter exactly this TAN. So if the user visits phishing pages he simply has no valid TANs anymore.

You should decide what kind of TAN you really need according to the security requirements you have. Besides from creating TANs you should have an eye on the distribution channel (snail mail, e-mail, sms etc.) of your TAN lists. If you choose an unsafe way this can also put the user to risk.


You probably would be interested in the research by Simple Nomad.  He has done lots of research in this area and has been fingerprinting IPS devices for a while now.

Any in-line proxy that makes changes to the traffic can be fingerprinted.  Understanding the signatures used by the IPS is important to create packets to thwart them or to validate an IPS is in stream modifying the packets.


Based on the comment from nbering, I created a script that uses puttygen on Kali:

apt install putty-tools

The script is very basic but tries all words from a wordlist specified as the first argument. If the correct passphrase is found, it will prompt for user input, asking for a new passphrase to use to encrypt the private key.

#!/bin/bash

echo "Wordlist: $1"
echo "PPK file: $2"
echo "New PPK file: $3"
while read -r line
do
    echo $line > old_pass.txt
    error=$((puttygen $2 -P -o $3 --old-passphrase old_pass.txt ) 2>&1)

    if [[ ! $error = *"wrong passphrase"* ]]; then
        echo "Passphrase: $line $error"
    fi
done < $1

Hope this is helpful to someone. As always, only use with approval of the target.


Should every output element be filtered, or just those which contain user-editable data?

If there is no external interface to the lookup table, then you probably don't need to scrub the data coming out of those tables for security reasons. But it might be easier to always scrub data you are presenting rather than adding exceptions.

Also, if the data in the lookup tables is safe for HTML output, what happens when you switch to CSV output? Is it still safe? Still escaped properly?

"Defense in depth". You don't necessarily assume your database has been hacked, but you certainly should be defensively programming and not assuming that the database holds no bad characters, data, etc.

I recommend that you do input validation on the data coming in, output validation on anything you are writing out, and do each of those at each layer in the system (e.g., browser-web server, application-database).