your existing password. You
>> could conceivably write a custom script to encrypt all your current
>> passwords if you have a large number of existing files and don't want to
>> have people reset them all.
>>
>> Cheers,
>> Dan
>>
>> On Mon, Feb 8, 20
not.
>
> To turn it on, you set $BOLTcrypt = 'randomvalue'; in index.php before
> calling BoltWire. This will invalidate all your existing password. You
> could conceivably write a custom script to encrypt all your current
> passwords if you have a large number of exis
efore
> calling BoltWire. This will invalidate all your existing password. You
> could conceivably write a custom script to encrypt all your current
> passwords if you have a large number of existing files and don't want to
> have people reset them all.
>
> Cheers,
&
t all your current
passwords if you have a large number of existing files and don't want to
have people reset them all.
Cheers,
Dan
On Mon, Feb 8, 2016 at 6:36 AM TMurNGon wrote:
> Hi Dan,
>
> I notice that passwords are not being hashed, but rather stored as plain
> text in member
Hi Dan,
I notice that passwords are not being hashed, but rather stored as plain
text in member pages.
Have I neglected some setting?
Thanks.
Jan
--
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To unsubscribe from this group and stop
could keep the encryption type in site.config, but ask
> users to change or re-set passwords using the old encryption at login.
>
> If you're worried about plaintext passwords, then perhaps a script to
> go through the logins and check the length of the passwords stored
>
ning an issue brought up on the list, I've come to the
> conclusion it would be best to tighten up BoltWire's login system a
> bit.
>
> There is a security vulnerability based on BoltWire's ability to store
> passwords as either plaintext or encrypted. There is no easy wa
-set passwords using the old encryption at login.
If you're worried about plaintext passwords, then perhaps a script to
go through the logins and check the length of the passwords stored
could be a solution. I believe most encryption algorythms give fixed
length results, which are longer tha
After examining an issue brought up on the list, I've come to the
conclusion it would be best to tighten up BoltWire's login system a
bit.
There is a security vulnerability based on BoltWire's ability to store
passwords as either plaintext or encrypted. There is no easy way to
exp
Correcct. There's no farm config file automatically looked for, but I
suspect we could add one if needed. It might be useful...
Cheers,
Dan
On Sun, Sep 20, 2009 at 8:37 AM, Kevin wrote:
> Sorry... just figure it out...
>
> config is in the field directory...
>
> I moved the config.php there, r
Needed to rename the functions back to BOLTxmylogin and BOLTxmyregister to
work..
but it does work.
On Sun, Sep 20, 2009 at 5:37 AM, Kevin wrote:
> Sorry... just figure it out...
>
> config is in the field directory...
>
> I moved the config.php there, renamed the functions that I wanted to use
Sorry... just figure it out...
config is in the field directory...
I moved the config.php there, renamed the functions that I wanted to use as
mylogin and myregister and it works.
On Sun, Sep 20, 2009 at 5:32 AM, Kevin wrote:
>
> Dan,
>
> I'm trying to implement this so I don't have to keep ma
Dan,
I'm trying to implement this so I don't have to keep manually make the
change for every update. Not 100% sure how I will eventually
implement this so this would be good until I figure it out.
Not sure I am doing this right though.
It appears that the config.php file is looked for from a
On Mon, Sep 7, 2009 at 1:46 PM, Kevin wrote:
>
> On Sep 7, 9:24 am, The Editor wrote:
>> Kevin, sorry for not getting back to you earlier on this. Let me share
>> with you how I would recommend solving this problem.
>>
>> 1) Avoid any changes to the core functions. That means you will have
>> to
On Sep 7, 9:24 am, The Editor wrote:
> Kevin, sorry for not getting back to you earlier on this. Let me share
> with you how I would recommend solving this problem.
>
> 1) Avoid any changes to the core functions. That means you will have
> to remake the change every time theres an upgrade. This s
Kevin, sorry for not getting back to you earlier on this. Let me share
with you how I would recommend solving this problem.
1) Avoid any changes to the core functions. That means you will have
to remake the change every time theres an upgrade. This should be a
hard and fast rule--never change any
I just tried it and it works with a typo fixed...
function BOLTXencode($value, $field) {
## FUNCTION ENCODES A VALUE USING THE METHOD OF ENCRYPTIONG SET IN
SITE.CONFIG.
global $pageLink, $BOLTarray, $msg, $BOLTid, $BOLTmember,
$BOLTfieldKey;
$BOLTcrypt = BOLTconfig('BOLTcrypt');
$BOLT
Seems like by adding a encode function, you could add the ability to
choose which type of encoding to use, crypt or MD5 (could be others)
A function like
function BOLTXencode($value, $field) {
## FUNCTION ENCODES A VALUE USING THE METHOD OF ENCRYPTIONG SET IN
SITE.CONFIG.
global $pageLin
sword registration system to force update
the Boltwire's idea of where passwords are located. That is easy
enough.
I don't really need a one login access everything type system as the
user can just login to whatever tool they are going to use, it just
needs to see the same password fo
> 1) Can the password type be changed to MD5? Most of our other web
> packages use MD5 for passwords. If so, any idea which files would
> need to be modified. I didn't see a plugin for this.
Boltwire seems to use the PHP crypt function. Here is what I found
about the PHP
:
-
username1
username2
username3
~data~
author: admin
-
Questions...
1) Can the password type be changed to MD5? Most of our other web
packages use MD5 for passwords. If so, any idea which files would
need to be modified. I didn't see a plugin for
21 matches
Mail list logo
