Freeradius Crypt-Password authentication - freeradius

In radcheck table of freeradius mysql database, I can add few type of password.
For crypt password, where can I store the salt?

Usually the salt is prepended to the hash automatically by the crypt function, so you don't need to store it separately.
If you want everything to 'just work', you should be able to use the following format:
Password-With-Header := '{crypt}<crypt output>'
Then:
authorize {
sql
pap
}

Related

Freeradius: Authenticate users on certain condition

There is a network where users are using PPPoE to establish connections to the Access servers. We have lost the billing system and users' DB. The only condition that we know is that 'Valid credential should be credential where username and password are the same value. (i.e. username: johnsmith, password: johnsmith)'.
We'd like to recover access to the Internet asap.
Setup that we have now: Ubuntu 2004, accel-ppp, freeradius3. Everything works fine but we have to add a record for each user to raddb/mods-config/files/authorize file.
user1 Cleartext-Password := "user1"
user2 Cleartext-Password := "user2"
userN Cleartext-Password := "userN"
Updated: Is that possible to avoid manually adding users? The script should verify credential assuming that username and valid password are the same value.
This is trivial to do in unlang, FreeRADIUS's configuration language.
The "known" clear password to be matched in FreeRADIUS must be made available in the Cleartext-Password attribute. This is where it will generally be placed after a successful database lookup.
As you know the User-Name, you can update the password to match it. In sites-enabled/default you can add:
update control {
&Cleartext-Password = &request:User-Name
}
Adding this right at the bottom of the authorize{} section, and using = above (rather than :=) means that the Cleartext-Password attribute will only be changed if it hasn't previously been set by some other method, ensuring that as you add entries back into a database they will take precedence.
Authentication will then compare User-Name to Cleartext-Password; they will of course match so access will be permitted.

send an auto email with account details

I have a database and there some tables.
There are some users in the table users
I am trying to create a form which the user will be able to get his/her password to his/her email.
I would like to send an automatic email with both username and password (which are fields in the table named 'users')
//you can connect to you database with the following code
mysql_connect(HOST, USR, PSD);
mysql_select_db(DB);
/*where HOST = Database host server eg localhost
USR = Database username
PSD = Databse password
DB = The name of the database that contain the table
*/
place the code after
$id = mysql_real_escape_string($_GET['id']);
PS
using mysql is has been deprecated and remove as of php 7. Try to use PDO or MYSQLI
To connect to a database, please read this page. You need to connect to a database before you can perform any action with SQL in your file. Also consider security when sending account details by mail, especially unencrypted passwords. Even if you're practising it's a good exercise to make a secure system.

Grails - different passwords for same salt in Spring Security

My web app is using Spring Security plugin for authentication and authorization. I'm building sort of an API, where I need to verify user password.
Spring Security is configured to use BCrypt with 5 logrounds and username property as salt:
grails.plugins.springsecurity.password.algorithm = 'brcypt'
grails.plugins.springsecurity.password.bcrypt.logrounds = 5
grails.plugins.springsecurity.dao.reflectionSaltSourceProperty = 'username' // password salting
Now, in my controller I'd like to verify user password and login. For this, I call springSecurityService.encodePassword(cmd.password, cmd.username)
where cmd is command object with my params. The thing is, on each request, password encoded with springSecurityService is different and never the same as user password in databse. I tried also with constant values in encodePassword call, something like this:
springSecurityService.encodePassword('foo', 'bar') and result is the same: on each request encoded password is different. This way I can't verify user password and get valid user instance from databse.
Any ideas how to solve this?
bcrypt generates a uniq salt each time, and includes it into result hash. Because of it springSecurityService.encodePasswod just ignores second argument, and reflectionSaltSourceProperty option as well (see sources). So, each time you'll get different hash for same input data.
You can use BCrypt class to validate password, like:
if (BCrypt.checkpw(candidate_password, stored_hash))
System.out.println("It matches");
else
System.out.println("It does not match");
See docs for BCrypt: http://static.springsource.org/autorepo/docs/spring-security/3.1.x/apidocs/org/springframework/security/crypto/bcrypt/BCrypt.html
Btw, as you're using Spring Security, it's already implemented in framework, so you can use passwordEncoder bean:
def passwrodEncoder
...
passwordEncoder.isPasswordValid(user.password, cmd.password, user.username) //user.username will be ignored

How can I reuse Authlogic's password encryption functionality in a Rails app?

In my Rails app, I periodically require the user to re-enter their password after a certain amount of inactivity--like with sudo on Linux. My app uses Authlogic for authentication and handling password storage and encryption.
I need some method to encrypt the password the user enters using the exact same encryption scheme Authlogic uses to encrypt passwords when it verifies passwords during authentication. I need to 1) encrypt the password the user enters and 2) do a string comparison between this encryption and the encrypted password stored in the database for the user.
Where should I put the method to perform this encryption? Here are some ideas:
Idea 1 (in a new, custom module)
module PasswordCryption
include Authlogic::ActsAsAuthentic::Password
encrypt_password(password)
end
end
Idea 2 (in the User model)
class User
acts_as_authentic <---- makes Authlogic password encryption functionality available
encrypt_password(password)
end
end
Authlogic uses the SHA512 encryption by default. The clue is that authlogic repeated the hexdigest function 20 times. This will solve your problem:
digest = [raw_password, password_salt].join('')
crypted_password = 20.times { digest = Digest::SHA512.hexdigest(digest) }

Generate temporary URL to reset password

I am looking to implement a Forgot Password feature on my website. I like the option where an email containing a temporary one-time use URL that expires after some time is sent to the user.
I have looked at the following pages to get these ideas but I am not sure how to implement this using ASP.NET and C#. As one of the users indicated, if I can implement this without storing this information inside the database, that will be ideal. Please advise.
Password reset by emailing temporary passwords
Thanks.
Probably the easiest way is going to be to modify your users table to add 2 extra columns, OR if you don't want to modify the existing table you could add a new dependent table called "UserPasswordReset" or something like that. The columns are like this:
PasswordResetToken UNIQUEIDENTIFIER,
PasswordResetExpiration DATETIME
If you go with the additional table route, you could do also add the UserID column, make it a primary key and a foriegn key reference back to your users table. A UNIQUE constraint would also be recommended. Then you simply use a Guid in your asp.net application as the token.
The flow could be something like this:
User requests password reset for their account
You insert a new record in the table (or update their user record) by setting the PasswordResetExpiration to a date in the future (DateTime.Now.AddDays(1)), and set the token to Guid.NewGuid()
Email the user a link to your ResetPassword.aspx page with the guid in the query string (http://www.yoursite.com/ResetPassword.aspx?token=Guid-here)
Use the ResetPassword.aspx page to validate the token and expiration fields. (I.E. Make sure DateTime.Now < PasswordResetExpiration)
Provide a simple form that allows the user to reset this password.
I know you wanted to avoid modifying the database, but it really is probably the simplest method.
#Alex
You can also use System.Security.Cryptography classes in .NET for the hash algorithms. For example:
using System.Security.Cryptography;
...
var hash = SHA256CryptoServiceProvider.Create().ComputeHash(myTokenToHash);
...
Here, the System.Guid class in your friend, as it will generate a unique (well, unique enough) 128-bit number:
Generate a new Guid ( System.Guid.NewGuid() )
Store that Guid somewhere (Application object maybe?)
Send a custom URL in an email with that Guid
When the user hits the site, make them enter the password you sent in the email
If the passwords match, go ahead and force them to enter a new password
I used a Hashing Class to create unique automatic logins made up of the current date/time and the users email address:
string strNow = DateTime.Now.ToString();
string strHash = strNow + strEmail;
strHash = Hash.GetHash(strHash, Hash.HashType.SHA1);
get the Hash Class from: http://www.developerfusion.com/code/4601/create-hashes-md5-sha1-sha256-sha384-sha512/
Then just take it from the URL using:
if (Request.QueryString["hash"] != null)
{
//extract Hash from the URL
string strHash = Request.QueryString["hash"];
}
I would definitely include the database in this process. Once a reset is requested, it's a good idea to indicate that the account is locked out.
For example, if you are changing your pw because you think your account may have been compromised, you definitely don't want it to remain accessible while you go about the change process.
Also, inclusion of "real" information in the reset token could be decoded if someone really wants it and has the horsepower. It would be safer to generate a random string, save it in the db in the row for that user, and then key back to it when the link is clicked.
This gives you two things:
1) There's nothing to decrypt, and therefore nothing of value can be gained from it.
2) The presence of the token in the user record indicates that reset is in progress and the account should be treated as locked out.
The goal of sending some data|string to user email is validation of account owner. Please care about some points:
Avoid sending important information in reset or activate link.
It's best way to store unique string data conjunction with user
account and send it as that link. but be aware if you send just one
section as link to user email and just check it in page, your
application may be in dangerous by brute-force or dictionary
attacker. It's enough to check a list of string to find some links
and change password. I know that has a little chance, but not zero.
Result:
I think it's better if you
combine user email with string link then encrypt them
(not hash because hashed value can't be reverse) and send to user
email.
User click and your page get the encrypted value.
decrypt value.
extract user email.
find email in database.
compare string from received link with other one attached to user
email in database.
Good luck.
I'd use a hash code to validate details in the password reset url. This can all be done without writing anything to the DB or sending any privileged info to an attaker.
To briefly explain normal password salt and hashing; say the salt is 1111 and the pasword is password, you'd concatenate the two and hash the string 1111password, say this gives you a hash of 9999, you'd then store the original salt 1111 and hash 9999 in your user record.
When you are validating a password you use the stored salt, concatenate the password attempt, hash it and compare with the stored hash. For example asecret becomes 1111asecret but hashes to 8888. This doesn't match the original hash so the password match fails.
Of course the salt and hash would normally be properly generated and calculated with established crypto libraries (don't invent your own!).
For the password reset URL I'd put in the unique identifier for the user, i.e. email address, the date the request is made, and a new hash. This hash would be generated from those details concatenated together plus the salt and hash already stored for the user.
For example:
Email: user#example.com
Request Date: 2014-07-17
Salt: 1111
Hash: 9999
Generate a new hash of those concatenated, i.e. 'user#example.com2014-07-1711119999', say this gives a hash of 7777.
The URL I then generate would then have the email, request date and the new hash:
https:\\www.example.com\ResetPassword?email=user#example.com&requestdate=2014-07-17&hash=7777
The server will combine the email and supplied date with it's salt and hash and confirm the hash it generated is the same as the supplied one. If this is Ok then it will show the reset form with the same three parameters hidden behind it, otherwise an error. These get resubmitted and rechecked when the new password is entered to prevent that form being spoofed.
The email address needs to be supplied to make the request and it is only sent out in an email to the same address. the date is hardly priveleged info and the hash is not reversible so gives nothing anyway. Nothing has been written to the database and any tampering with the parameters causes the hash to fail and the URL to report an error.
There is an issues with this approach. A safe hash makes the token really long. Either you integrate the salt into the hash itself (makes it about 20 charactes longer), or you store this unique salt in the database. If you store the salt in the database, you could as well store a random token which is not derrived from any existing
Depending on your needs, you could encrypt information, in a format similar to the following format
(UserId)-(ExpireDate)
Encrypt the data, make that the link, then decrypt the data and take action from there...
Crude, but most likely usable, and not requiring DB usage

Resources