L’article Le député Philippe Juvin invite l’État à transférer ses compétences est apparu en premier sur Institut économique Molinari .

L’article Réforme des retraites: le recul de l’âge de départ est-il vraiment nécessaire? est apparu en premier sur Institut économique Molinari .

L’article Virus hivernaux: ces pics épidémiques que nous ne verrons pas venir est apparu en premier sur Institut économique Molinari .

Related Stories

• How to Take Winter Photos That Aren’t White and Blurry (Unless That’s the Point)
• Your Hotel Mini-Fridge Might Not Be a Real Fridge
• The 7 Deadly Sins of Learning How to Cook

ISPs and telecoms are often legally required to keep user accounting data for long periods of time. However, keeping these records can result in enormous databases which then affect the performance of your RADIUS system. There are ways of optimizing the database so that you can keep high performance while maintaining years of accounting data.

Database performance slows down as the size of the database increases

This limitation is potentially bad news for organizations who are legally required to maintain years of historical data. At any point in time, law enforcement might request records of user activity from several years ago. For large ISPs and Telecoms who have millions of users, historical databases can quickly mushroom into terabytes of data.

If the RADIUS deployment uses a single database table which maintains both the historical data and live sessions, it will have enormous indexes that need to be updated with every new session. In a database with a hundred millions rows, adding a new row can take many seconds, where normally it should take less than a tenth of a second. This performance drop can create a huge bottleneck in the RADIUS system, and can prevent users from getting online.

We recommend maintaining separate databases for the historical data and the current data, especially in situations where the historical data is very large.

The design is very straightforward.

• The “currently online” database maintains records for one or two months
• Once or twice a day, an automated process finds all the old, closed sessions in the current database and copies them into the historical database, and then removes those records from the current database.

These operations will be efficient because they are mostly bulk transactions, and can update hundreds of rows efficiently. Furthermore, because the appends are not being performed on the database used by RADIUS, any slow transactions will not impact the RADIUS system, and will not affect user experience.

The result is that the current database can be maintained at a very small size, so that updates can be done within milliseconds. At the same time, the historical database is available for the occasional query from law enforcement, or for accounting queries during the billing cycle.

The idea behind these changes is that database queries in a RADIUS system must be fast to computers. However, database queries for law enforcement must be fast to people, The difference is that computers need millisecond latency, and humans are happy with multi-second latency. This fact means that the databases used by RADIUS must be small and fast, while the databases used for law enforcement can be large and slow.

It is worth noting that both the current and historical databases will typically have the same schema . However, their uses are very different.

The historical database serves as long-term data storage, with potentially hundreds of millions of rows. The actions on it will generally be append-only and there will be very few read transactions.

The current database is used for short-term storage, with about as many rows as users. The transactions on this database will generally be updating the same user session data over and over again.

When to use this solution

In scenarios where there is no requirement to archive user sessions for several years, or if the historical database is relatively small, is generally safe to put both sets of data into one table. However, the old data should be periodically deleted! The division of usage between the databases is most effective when applied to organizations that serve millions of users and sessions every day. Most commonly, large ISPs and Telecoms are in this situation.

Need more help?

Network RADIUS has been helping clients around the world design and deploy their RADIUS infrastructure for 20 years. We specialize in complex systems and have seen pretty much every variation and problem out there. If you want help from the people who wrote FreeRADIUS, visit our quote page to contact us for a consultation.

Značky: #Network, #articles

A common misconception is that PAP is less secure than other authentication protocols such as CHAP, MS-CHAP, or EAP-MSCHAP(v2). This perception arises because of a misunderstanding of how PAP is actually used.. In fact, PAP is often the most secure authentication protocol option available, and it’s what we usually recommend people use.

How can clear-text be secure?

PAP transmits passwords in clear-text. This is the attribute which makes people believe that PAP is insecure. After all, how can a clear-text be secure?

The truth is that PAP does not transmit passwords in clear-text over the network. This critical point is usually overlooked.

The only part of the authentication process where PAP is transmitted “unprotected” is between the customer DSQL equipment and the NAS (see Figure 1). Although it is technically possible to intercept this communication, it requires physical access to the wires between the customer or the ISP.

Figure 1: How PAP works

While this physical obstacle does not completely eliminate the risk of intercepting the password, the reality is that in practice, the risk is negligible. The only groups that are remotely likely to conduct covert operations that involve sneaking onto premises are government actors. This type of espionage is out of reach for your average hacker.

It’s also too expensive for the average attacker to drive your house, and hook up equipment to your DSL line.

The average hacker is much more likely to target the user database from the comfort of their own home, rather than to risk sneaking onto your home property. By far, the most common way to get peoples passwords is by breaking into the database which stores passwords.

In the event of a database breach, using PAP in your RADIUS ecosystem provides far better security than other protocol options. This is because when you use PAP, passwords can be stored in salted / hashed form. This is the most secure form of password storage. It means that if (or when) an attacker copies the database contents, they cannot use that information to “crack” peoples passwords.

In contrast, when you use CHAP, passwords must be stored in the database in plain-text format (See Figure 2). This means that if an attacker copies the database contents, they can see everyones password in the clear! It’s hard to imagine anything worse for security than having your password stolen.

Figure 2: How CHAP works

It is important to note that this is not because of any inherent insecurity within the CHAP protocol itself, but with the constraints it puts on how passwords are stored in the database.

Choose your Shared Secrets wisely, they secure PAP!

When configuring FreeRADIUS, you must specify a “shared secret” between RADIUS and the NAS. This shared secret is used to secure the PAP passwords when they are sent over the network. A strong shared secret makes it difficult or impossible for an attacker to “crack” the passwords. We recommend a long (16 character or more), and random shared secret. Don’t use dictionary words!

As we see in step 3 of Figure 1, the NAS uses MD5 to create an encryption key which is based on the shared secret. Many people will see that “MD5 is broken”, and will worry about the security of this operation, but there is no cause for alarm.

MD5 is not perfect, but the shared secret makes it OK to use . In fact, after over three decades of analysis, there has yet to be a vulnerability found with how RADIUS uses MD5. All of the discussions of “MD5 is cracked” are for using MD5 in different ways, where there is no shared secret.

There is an important caveat however. The security of the MD5 encryption depends significantly on the choice of the shared secret between RADIUS and the NAS. If the Shared Secret is a weak password such as “hello” or “123password”, then it can be decrypted by brute force methods. However, if the shared secret is a strong choice such as Lf34^_QrTB*wbec0 , then it cannot be practically broken.

In the FreeRADIUS default distribution, the default shared secret is testing123 . Be sure to only use this shared secret for testing purposes, and to change it as soon as possible!

But I read that CHAP is more secure than PAP

It is true that much of the information online suggests that CHAP is more secure than PAP. However, many of the articles that make this claim contain half-truths, inaccuracies, and outright nonsense. See our recent article which debunks each of the claimed “facts” about PAP vs CHAP ..

The bottom line

The most meaningful distinction between PAP and CHAP is really where clear text passwords are stored or transmitted. The distinction is not a naive repetition of “one is secure, and the other is not”.

When PAP is used, the most vulnerable part of your network is at the physical wires between the customer and the ISP. Due to historical issues with PPP the password is transmitted in clear text between these two points. Any attacker who can watch this link will only see one password.

When CHAP is used, the most vulnerable part of your network is your database , because the passwords must be stored there in clear text. Any attacker who gets into the database will see everyones passwords.

You already know this trade-off. Think back to the last dozen or so password breaches you read about in the media. How many of them were due to database breaches, and how many of them were due to physically intercepting traffic across wires? Database breaches are common, but we are hard pressed to find a single example of attackers breaking into networks by physically tapping into wires. That kind of attack is limited to governments with millions of dollars of equipment, and the movies.

The analysis we have done here is just one of the reasons we always recommend using PAP whenever possible . It’s more secure, it works in more situations, and it’s easier to use.

Need more help?

Network RADIUS has been helping clients around the world design and deploy their RADIUS infrastructure for 20 years. We specialize in complex systems and have seen pretty much every variation and problem out there. If you want help from the people who wrote FreeRADIUS, visit our quote page to contact us for a consultation.

Značky: #Network, #articles

One of the most common questions about RADIUS security asks “Is PAP secure?” The usual answer is “no”, which is (in our opinion) seriously misleading. A better answer is “Here’s a comparison of PAP and CHAP, so that you can make an informed decision for yourself”. The end result? It may not be what you think!

There is a lot of confusion around the security of PAP versus CHAP. While there are many web sites which clain to compare the security of these two authentication methods, most of these comparisons are shockingly wrong . We are writing this, and other, articles in order to correct the misconceptions around PAP vs CHAP. We will go through the misconceptions one by one, explain why they’re wrong, and what the real answer is.

The points below are summarized from a variety of other sites which give the poor advice about PAP versus CHAP. We won’t link to the sites which contain these misconceptions. There is no reason to give them additional traffic or page ranking.

Claim: PAP is a two-step process, CHAP is a three-step process

This point has very little to do with security, of course. Worse, this statement is true true only for the PPP link between the end-user system and the NAS. Both PAP and CHAP end up in a RADIUS Access-Request packet, which gets an Access-Accept (or Access-Reject ) reply.

Which means that when we look at how PAP and CHAP are used outside of that single PPP link, they are both a two-step process.

Claim: CHAP can do multiple authentications per session, and PAP cannot.

It is true that RFC 1994 Section 2 says that in PPP, any CHAP authentication “ is done upon initial link establishment, and MAY be repeated anytime after the link has been established. ” (emphasis in original).

However, this statement is not true for RADIUS . There are no provisions in RADIUS for a user to re-authenticate in the middle of a session.

Which means that when RADIUS is being used, both PAP and CHAP authenticate the user once , and that’s that.

Claim: CHAP is more secure, as the passwords are encrypted, while PAP sends passwords in the clear

This statement is true only for limited scenarios. Most of the time this claim is seriously misleading, if not outright wrong.

It is true that when PPP is used, the PAP passwords are sent over the PPP link in “the clear”. However, this statment is not true for every other situation where PAP is used.

When a PAP password is sent in a RADIUS packet, the password is encrypted using the shared secret. It is therefore impossible for an attacker to see the PAP password in a RADIUS packet. (Despite that security, we still recommend using RADIUS over TLS or IPSec, for a host of reasons.)

The truth is that protocol designers aren’t stupid. If a protocol needs to send PAP passwords, those passwords are almost always encrypted and/or secured via TLS. The only time the passwords aren’t secure is in historical protocols such as PPP, which are used in very limited situations, where the links are physically secure.

In fact, this is main place where people can “sniff” cleartext PAP passwords: the DSL link between a home router and your ISP.

So you have to ask yourself, what’s more likely, that someone will “tap” your local phone line and steal one password? Or that someone will attack your local ISP, and steal all of the passwords from its database?

Before you jump into giving an answer, we suggest checking the Have I been pwned site. There is a high probability that one or more of your accounts are already listed there.

The problem of an ISP or enterprise losing its password database is made worse by the issues discussed in the how authentication protocols work and protocol compatibility pages. Without repeating those articles, using CHAP means that all passwords have to be stored as clear-text in the database . Whereas using PAP means that passwords can be stored securely in the database .

When passwords are stored securely in the database, then it matters a lot less if an attacker steals a copy of the database. Modern password storage methods make it extremely difficult for an attacker to run “brute-force” cracking tools on stolen passwords.

Which means that for almost all possible situations it is much more secure to use PAP rather than CHAP.

Claim: CHAP sends encrypted usernames and passwords, while PAP sends unencrypted usernames and passwords

This statement is wrong.

CHAP does not encrypt user names.

Claim: CHAP is more secure, as it only sends the user name, while PAP sends the user name and password over a link

This statement is simply bizarre.

CHAP does send a version of the password over the link. Anyone who says otherwise is seriously confused about how CHAP works. An attacker who can see the PAP password (over PPP) can also see the entire CHAP exchange, too.

An attacker who can observe the PPP link can still crack CHAP authentication via “brute-force” attacks. Which means that this comparison is simply wrong, and misleading.

Claim: CHAP protects from trial-and-error attacks, PAP does not.

This statement is also wrong.

There are no provisions in PPP / CHAP for preventing “brute force” trial and error attacks. Anyone can try to log in again and again, either with CHAP or with PAP. There are no differences between the two for trial-and-error attacks.

Claim: PAP is less widely used than CHAP, due to the insecurity of PAP

Our experience at Network RADIUS has been the opposite. PAP is much more widely used than CHAP.

We will give our recommended choice at the end of this article. Though we are sure that by now, you can probably guess which one we recommend.

Claim: CHAP authentication is done by both client and server, PAP is only done on the server side

This statement is wrong.

CHAP does not allow for a server to authenticate itself to a client or end-user machine.

The MS-CHAP authentication protocol allows for two-way authentication, but it has many of the same issues as CHAP.

Claim: PAP is only for authenticating users, CHAP can authenticate users or network hosts

It is not clear where this claim originates from, but it has nothing at all to do with network security.

Both CHAP and PAP are generally carried inside of PPP, which authenticates one end of the PPP link. The nature of PPP means that it can be used for any situation which requires authentication, user or network host.

Our Recommendation: PAP or CHAP?

As we have seen above, the typical claims about PAP versus CHAP security are wrong, misleading, confused, or just irrelevant.

But before we give our answer, we would like to give one additional point about why we are making this particular recommendation.

The truth is that network security is about the security of your entire network . You cannot look at one piece in isolation, and declare “this one thing is secure, so the rest of the network must be secure, too”.

There are always trade-offs in security. A decision made for one part of the network can affect other parts of the same network. As a result, any purely “local” approach to network security is guaranteed to result in a less secure network .

So the real question we should be answering is not “which is more secure, PAP or CHAP?”. Instead, the question we should be answering is “Which one (PAP or CHAP) allows your entire network to be as secure as possible?”

The answer is, of course, PAP .

For people who understand the trade-offs between PAP and CHAP, this is the only answer. We always recommend that our customers use PAP instead of CHAP. We only configure systems with CHAP when, for historical reasons, the customer cannot use PAP.

Need more help?

Network RADIUS has been helping clients around the world design and deploy their RADIUS infrastructure for 20 years. We specialize in complex systems and have seen pretty much every variation and problem out there. If you want help from the people who wrote FreeRADIUS, visit our quote page to contact us for a consultation.

Značky: #Network, #articles

One-time passwords (OTP) and multi-factor authentication (MFA) are important mechanisms used to improve security. Both these strategies can combine the username and password credentials with a one-time token as part of the sign-in process. The one-time token is usually supplied through an authentication app, or a small separate piece of hardware. In network security, using a one-time token is common practice for activites such as signing into private networks through VPN.

While one-time passwords are useful, the authentication method that is used to transmit the user’s credentials may not be compatible with the use of OTP.

Specifically, only PAP makes it possible to incorporate OTPs or MFA into the authentication process.

This article explains how one-time tokens work, and why PAP is the only authentication protocol which can support them.

How PAP works

When PAP is used, the RADIUS client sends the password to the RADIUS server. The password is, of course, encrypted “on the wire” so that no one else can see it. But the key benefit of PAP is that the RADIUS server gets a copy of the users’ password, and OTP . With all other authentication methods (CHAP, MS-CHAP, etc.) the RADIUS server gets a hashed version of the passwords. This hashed version effectively hides the OTP, meaning that all benefits of using an OTP are lost.

Figure 1: How PAP works

One primary benefit of PAP authentication is that the clear-text password is compatible with all databases and other back-ends . Using PAP allows you to store passwords in the database in salted, encrypted form. i.e. a secure storage method which provides protection against database breaches.

Another significant benefit of PAP authentication is that it is compatible with the use of one-time tokens .

How PAP works with one-time passwords

One-time tokens are typically generated with an authentication app such as Google Authenticator, or a piece of hardware with a small display. These apps cycle through six-digit tokens, which the user reads and then enters along with the password when logging in, for example “ 123456mypassword ”.

Because the password is transmitted via PAP, the RADIUS server can see the entire password field and can split the value “ 123456mypassword ” into two parts. The token part: “ 123456 ” is verified against the OTP token server. The password part “ mypassword ” is verified against the user directory such as LDAP or Active Directory in the usual way. If either check fails, the user is rejected. If both checks pass, the user is authenticated.

Figure 2: How PAP works with one-time passwords

How PAP works with challenge-response authentication

Another implementation of one-time tokens breaks the authentication into two steps, via a challenge-response process.

In this method, the user enters a password such as “ mypassword ”. For the first step of the authentication, the RADIUS server verifies the password against the user directory as in Figure 1. The only difference in this case, is that if the password is correct, the RADIUS server returns a RADIUS Access-Challenge packet, containing a test such as “ Please enter the token: ”, rather than an Accept or Reject response.

Figure 3: Two-step challenge-response authentication with PAP (step 1)

The RADIUS client displays this challenge to the user, who enters the token, e.g. “123456”. This token is then passed to the RADIUS server, which verifies it against the OTP token server.

Figure 4: Two-step challenge-response authentication with PAP (step 2)

Will OTPs work with CHAP?

No. CHAP is not compatible with the use of one-time tokens.

With CHAP authentication, the RADIUS client calculates a MD5 hash of a random challenge and the user’s password. Both the challenge and MD5 hash are sent to the RADIUS server. But the password is never sent. Which means that the OTP is never sent to the RADIUS server!

Figure 5: How CHAP works

When the RADIUS server receives the CHAP password, it just sees an opaque hash, and not the OTP value “ 123456 ” or the password “ mypassword ”. If a one-time token is prepended to the password, the RADIUS server has no way to “reverse” the hash in order to see the OTP or the password. This means that RADIUS cannot validate the token with the OTP server.

But what about the 2-step challenge-response process? In this case, the password forwarded by the NAS can be verified by the RADIUS server in the usual way, as in Figure 5. However, when the user supplies the one-time token after the challenge, the RADIUS client once again applies an MD5 hash and random challenge before transmitting it.

When the RADIUS server receives this hashed content, it can only pass the hashed version of the token to the OTP server for validation. The OTP server doesn’t have visibility into the actual value of the token, which means it cannot validate the token, which means RADIUS cannot validate the authentication attempt.

Are MS-CHAP or EAP-MSCHAP compatible with OTPs?

Sadly, no.

The constraints that apply to OTPs and CHAP apply in the case of MS-CHAP and EAP-MSCHAP as well.See our previous article for a detailed description of how these protocols work.

The bottom line

Fundamentally, in order for OTPs to work, the one-time token must be validated separately from the password .

In all protocols other than PAP, this is not possible because the value of the one-time token cannot be extracted from the packet payload received by RADIUS.

In general, we recommend using PAP whenever possible. It is secure, and is compatible with everything.

Still need help?

In our experience with clients and in troubleshooting conversations we manage in the FreeRADIUS mailing list, an unresponsive child error is a symptom of a fundamental underlying issue with the larger infrastructure design. If you have a complex network environment and need expertise from the people who wrote FreeRADIUS, contact us for a consultation.

Značky: #articles, #Network

Choosing an authentication protocol is one of the most important decisions when designing a RADIUS ecosystem.

There are a variety of authentication protocols to choose from, each with their own set of advantages, disadvantages, and constraints. In general, we recommend using PAP whenever possible . It is compatible with all known back-end databases, and it has no known security issues.

This article outlines the most common authentication protocols, how they work, and the implications of using them.

When evaluating authentication protocols, you should consider criteria such as:

• How secure is the authentication protocol?
• Will this authentication protocol be compatible with how passwords are stored in the database?
• Is this authentication protocol able to handle multi-factor authentication?

Overall, PAP performs the best for all of these criteria.

How does PAP authentication work?

RADIUS provides for PAP authentication, in which the RADIUS client sends a clear-text password to the RADIUS server. This clear-text password is encrypted in transit. Despite nearly three decades of analysis, there have been no vulnerabilities found with this encryption.

The benefit of PAP authentication is that the clear-text password is compatible with all password “encryption” methods, databases, and other back-ends. The RADIUS server can use the password in whatever way it needs in order to validate the credentials. For example using LDAP “bind as user” to “log in” to the LDAP server as the user. If the login is successful, the RADIUS server returns “accept”, otherwise it returns “reject”.

The only security issue with PAP is that the RADIUS server sees this password. If the RADIUS server is compromised, then the passwords may “leak”. However, if the RADIUS server is compromised, then leaking passwords is only a small proportion of bad things which can happen. In general we recommend using PAP as much as possible. It is secure, and compatible with everything.

And before anyone says “PAP is insecure”, it’s really not. The reason why is best left as the subject for another article. Just be sure to have a strong shared secert, and leave it at that. Something like secret is bad. Ddq9Dn^bjf82bH8b is better.

How does CHAP authentication work?

RADIUS also supports CHAP authentication. In this authentication method, the RADIUS client calculates a MD5 hash of a random challenge, and the user’s password. Both the challenge and password are sent to the RADIUS server.

The RADIUS server then obtains the user’s clear-text password from a database. The server then performs the same MD5 hash of the random challenge and the clear-text password. If the two hashes are identical, then the password entered by the user is correct, and the RADIUS server returns “accept”. Note that only a clear-text password will work! Any “crypted” password will not work with CHAP.

The security issues with CHAP are largely the same as with PAP. For CHAP, the passwords are never send, even encrypted, and the RADIUS server has access to the users clear-text password. Despite nearly three decades of analysis, there have been no vulnerabilities found with CHAP.

The downside to CHAP authentication is that the RADIUS server must obtain the user’s clear-text password from a database. If that password is not available (e.g. as with Active Directory), then the RADIUS server cannot perform the CHAP calculations necessary to authenticate the user.

How does MS-CHAP authentication work?

MS-CHAP authentication is similar in some respects to CHAP, except that the calculations are done with MD4 and DES instead of MD5. MS-CHAPv2 is slightly different from MS-CHAPv1, but the underlying design principles are the same.

The problem with MS-CHAP is that the underlying design is fundamentally flawed. Both MD4 and DES have been cracked since the protocol was designed. In addition, the way MS-CHAP uses DES makes it almost trivial to reverse engineer the DES keys used. Microsoft has acknowledged this weakness in their web site at the following page:

https://msrc-blog.microsoft.com/2012/08/20/weaknesses-in-ms-chapv2-authentication/

Anyone who can observe the MS-CHAP exchange can run easily available “cracking” tools, such as this one on GitHub: https://github.com/moxie0/chapcrack

As of 2012, the authors of the above tool were offering to crack any MS-CHAPv2 exchange for $20, and obtain the users password:https://boingboing.net/2012/09/24/exhaust-all-of-des-and-crack-a.html

We can only assume that the cost of cracking MS-CHAPv2 has dropped significantly since then.

Due to the above issues, we recommend using MS-CHAPv2 only when no other alternatives are available . We also recommend that all RADIUS traffic carrying MS-CHAPv2 be sent over secure, management networks.

How does EAP MS-CHAPv2 authentication work?

EAP-MSCHAPv2 is essentially MS-CHAPv2 carried over the EAP protocol. EAP is an authentication protocol which is little more than a framework for carrying other authentication protocols. It consists of a four (4) byte header which contains a 1-byte identifier that tracks requests and responses, a 1-byte field which identifies the EAP type being carried, and finally 2 bytes which describe the length of the data being carried.

For EAP-MSCHAPv2, the data being carried in EAP is just MS-CHAPv2.

The underlying EAP protocol requires additional packet exchanges over normal MS-CHAPv2. As such, it is more complex to implement.

In the end, EAP-MSCHAPv2 is essentially MS-CHAPv2, but is more complex. EAP-MSCHAPv2 adds no additional security or integrity checks over MS-CHAPv2.

Recommendations

Our recommendation is to use PAP whenever possible . It is compatible with all known back-end databases, and it has no known security issues. The Microsoft MFA (Multi-Factor Authentication) server supports MFA with PAP. FreeRADIUS can do OTP (One Time Passwords) with PAP and Active Directory. For WiFi or 802.1X, we recommend using TTLS with PAP in the “inner tunnel” authentication.

Further, we recommend using passwords where the users password is appended to the OTP token, e.g. 123456mypassword . That form is simple to use for both users and administrators.

If MS-CHAPv2 is required for operational or inter-operability reasons, we recommend running it over a secure management network. The Microsoft MFA server does not support MFA with MS-CHAPv2. Or, running TTLS + MS-CHAPv2. Though it has no benefits (and many drawbacks!) over TTLS + PAP.

We do not recommend using EAP-MSCHAPv2, as it offers no benefits over MS-CHAPv2, and it is more complex to implement.

Still need help?

In our experience with clients and in troubleshooting conversations we manage in the FreeRADIUS mailing list, an unresponsive child error is a symptom of a fundamental underlying issue with the larger infrastructure design. If you have a complex network environment and need expertise from the people who wrote FreeRADIUS, contact us for a consultation.

Značky: #articles, #Network