seeseekey.net - Invictus Deus Ex Machina

Wenn man das ownCloud-Passwort ändern möchte, so kann man dies über die „Pass­wort vergessen?“-Funktion zurück­set­zen. Wenn dies nicht mehr mög­lich ist, so kann das ganze auch in der Daten­bank erle­digt werden:

UPDATE `oc_users` SET `password`=SHA1('geheim') WHERE `uid`='nutzername'

Da die Pass­wör­ter mit einem Salt und mit­tels SHA1 gehasht gespei­chert wer­den, muss das neue Pass­wort auch gehasht wer­den. Dies erle­digt die Datenbank-Funktion „SHA1“ für uns. Nach­dem das Pass­wort zurück­ge­setzt wurde, sollte das Pass­wort nach dem Login über die „Persönlich“-Seite erneut geän­dert wer­den, damit wie­der ein Salt für sel­bi­ges gene­riert wird.

Wer unter der aktu­el­len Ver­sion von own­Cloud (5.0.7) ver­sucht das Pass­wort des ange­mel­de­ten Nut­zers zu ändern, kann durch­aus mit der Meldung:

Class 'OCA\Encryption\Util' not found at /www/htdocs/owncloud/settings/ajax/changepassword.php#31

beglückt wer­den. Der Feh­ler tritt immer dann auf wenn die App „Encryp­tion“ nicht aktiv ist und man das Pass­wort ändern möchte. Um den Feh­ler zu umge­hen gibt es zwei Mög­lich­kei­ten. Die erste Mög­lich­keit ist die Akti­vie­rung der ent­spre­chen­den App um anschlie­ßend das Pass­wort zu ändern. Die zweite Mög­lich­keit ist es den Patch wel­cher im Bug­re­port ver­linkt ist, in die eigene own­Cloud Ver­sion zu inte­grie­ren. Danach klappt es mit dem Passwortwechsel.

Wenn man ein Jenkins auf­setzt kann es pas­sie­ren das man sich beim Tes­ten des Menü­punk­tes „Glo­bale Sicher­heit kon­fi­gu­rie­ren“ aus dem Sys­tem aus­sperrt. Um die­sen Zustand zu ändern, been­det man Jenkins ein­fach und sucht nach der „config.xml“ der Soft­ware. Dort gibt es einen Tag namens „useSe­cu­rity“ des­sen Wert ein­fach auf „false“ setzt. Danach sollte man Jenkins wie­der star­ten und kann ohne Zugriffs­be­schrän­kun­gen auf das Sys­tem zugrei­fen, bis man sich wie­der mal aussperrt.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://de.wikipedia.org/wiki/Jenkins_(Software)

Wenn man das lokale Pass­wort für einen Win­dows­rech­ner ver­ges­sen hat so ist das ärger­lich, kann aber dank ntpasswd sehr schnell beho­ben wer­den. Schwie­ri­ger wird es wenn man das admi­nis­tra­tive Pass­wort in einer Win­dows Domäne ver­legt hat. Hier kommt man mit „ntpasswd“ nicht sehr weit, auch die Win­dows Bord­mit­tel hel­fen im ers­ten Moment nicht. Aller­dings gibt es natür­lich auch hier Mit­tel und Wege, in die­sem Bei­spiel anhand des Win­dows Ser­ver 2003 beschrieben.

Im ers­ten Schritt sollte das Pass­wort für die „Ver­zeich­nis­dienst­wie­der­her­stel­lung“ auf eine leere Zei­chen­kette gesetzt wer­den. Dies geschieht mit­tels „ntpasswd“. Dort leert man ein­fach das Pass­wort für den Nut­zer „Admi­nis­tra­tor“. Nach­dem dies erle­digt ist drückt man beim Start von Win­dows im rich­ti­gen Moment die F8 Taste damit die erwei­ter­ten Windows-Startoptionen geöff­net wer­den. Dort wird der Punkt „Ver­zeich­nis­dienst­wie­der­her­stel­lung (Windows-Domänencontroller)“ aus­ge­wählt. Das Win­dows wird damit im abge­si­cher­ten Modus gestar­tet. Der Login lau­tet dabei „Admi­nis­tra­tor“ ver­bun­den mit einem lee­ren Passwort.

Für den nächs­ten Schritt benö­tigt man die „Win­dows Ser­ver 2003 Resource Kit Tools“ wel­che unter http://www.microsoft.com/en-us/download/details.aspx?id=17657 her­un­ter­ge­la­den wer­den kön­nen. Den Instal­ler sollte man unter Umstän­den mit einem Pack­pro­gramm sei­ner Wahl (z.B. 7-Zip) ent­pa­cken, so das man die ent­hal­te­nen Dateien zur Ver­fü­gung hat. Bei ent­spre­chen­der Ser­ver­kon­fi­gu­ra­tion kann es näm­lich pas­sie­ren, das der Instal­ler als sol­ches nicht auf dem Domain­con­trol­ler aus­ge­führt wer­den darf.

Aus dem „Win­dows Ser­ver 2003 Resource Kit Tools“ wer­den die Dateien „instsrv.exe“ und „srvany.exe“ benö­tigt. Diese kopiert man sich in ein Ver­zeich­nis sei­ner Wahl z.B. nach „C:\Temp“. Danach öff­net man die Kom­man­do­zeile, wech­selt in den Ord­ner und gibt dort fol­gen­des ein:

instsrv tmpService "C:\Temp\srvany.exe"

Im nächs­ten Schritt müs­sen die Para­me­ter des Diens­tes „tmp­Ser­vice“ in die Regis­try ein­ge­tra­gen wer­den. Dazu wird der Regis­trie­rungs­edi­tor mit­tels „rege­dit“ gestar­tet“ und dort der Schlüs­sel (bzw. der Ordner):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tmpService

gesucht. In die­sem wird ein neuer Schlüs­sel mit dem Namen „Para­me­ters“ ange­legt und in die­sem wer­den fol­gende Zei­chen­fol­gen angelegt:

Application -> C:\Windows\System32\cmd.exe
AppParameters -> /k net user Administrator neuesPasswort /domain

In der „Sys­tem­steue­rung“ sollte danach in der „Ver­wal­tung“ das Fens­ter „Dienste“ geöff­net wer­den und dort nach dem Dienst „tmp­Ser­vice“ gesucht wer­den. In den Eigen­schaf­ten wird als Start­typ „Auto­ma­tisch“ sowie unter „Anmel­den“ der Haken bei „Daten­aus­tausch zwi­schen Dienst und Desk­top zulas­sen“ akti­viert. Nach­dem der Dia­log bestä­tigt wurde kann der Rech­ner neu­ge­star­tet werden.

Beim Neu­start wird das Pass­wort nun auf „neu­e­sPass­wort“ gesetzt und es ist mög­lich sich mit die­sem ein­zu­log­gen. Nun muss der ent­spre­chende Dienst wie­der deak­ti­viert und ent­fernt wer­den. Dazu gibt man in der Kom­man­do­zeile fol­gen­des ein:

net stop tmpService
sc delete tmpService

Als letz­ter Schritt müs­sen nur noch die kopier­ten Dateien gelöscht wer­den. Das Pass­wort des Domain­con­trol­lers wurde damit zurückgesetzt.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://de.wikipedia.org/wiki/Domain_Controller

Vor eini­gen Tagen kam die Ver­sion 2.0 der Anwen­dung Out­bank her­aus. Dabei han­delt es sich um eine Ban­king Soft­ware für Mac OS X und iOS. Aller­dings hatte sich in die Ver­sion ein schwe­rer Feh­ler ein­ge­schli­chen. So wurde das Pass­wort wel­ches zu loka­len Ver­schlüs­se­lung der Daten benutzt wird, im Klar­text in die „system.log“ geschrie­ben, was dann im Bei­spiel so aussieht:

Jan 17 09:17:03 delphi.localdomain OutBank[537]: Open Store:Core Data key:123456->abcdefghijklmnopqrstuvwxyzABCDEF

Neben die­sem Pro­ble­men hatte die erste Ver­sion dank iCloud Syn­chro­ni­sie­rung auch mit Pro­ble­men wie dop­pel­ten Umsät­zen und ähn­li­chem zu kämp­fen. Pro­ble­ma­tisch an dem Feh­ler im Log ist auch das Mac OS X von Zeit zu Zeit das ganze archi­viert und es so dazu kom­men kann, das die­ses Pass­wort an meh­re­ren Stel­len zu fin­den ist. Das glei­che trifft auch auf die Kom­bi­na­tion mit Back­u­p­sys­te­men wie Time Machine zu. Um nach dem Update auf Out­bank die ent­spre­chen­den Log­ein­träge zu ent­fer­nen wird von „sto­e­ger it“ fol­gende Zeile emp­foh­len wel­che man im Ter­mi­nal aus­füh­ren sollte:

sudo -i -- 'cd /var/log && grep -vE "OutBank\[" system.log > system.log.clean && mv system.log.clean system.log && if [[ -f system.log.0.bz2 ]]; then for a in system.log.*.bz2; do bunzip2 $a && grep -vE "OutBank\[" ${a%.*} > ${a%.*}.clean && mv ${a%.*}.clean ${a%.*} && bzip2 ${a%.*} ; done; fi; rm -f /var/log/asl/*.asl'

Wit­zig sind in die­sem Zusam­men­hang Aus­sa­gen von Tobias Stö­ger aus der Zeit­schrift SFT (Spiele | Filme | Tech­nik) wo er auf die Frage ob Out­bank sicher ist unter ande­rem wie folgt ant­wor­tet:

Der Arti­kel bezog sich mal wie­der auf das unsi­chere Android-OS. […] Hinzu kom­men noch unsere Sicher­heits­maß­nah­men, wie auto­ma­ti­sche Pass­wort­sperre oder ver­schlüs­selte Datenbank.

Das war dann wohl ein Fall von pau­scha­ler Aus­sage zum fal­schen Zeit­punkt. Natür­lich stellt sich die Frage warum (wenn auch nur für Debug­zwe­cke) Pass­wör­ter über­haupt im Klar­text gespei­chert wer­den. Auch war keine Aus­kunft zu erhal­ten ob die neue Ver­sion von Out­bank die Berei­ni­gung der Dateien sel­ber vor­nimmt. Zur Sicher­heit sollte man dies also auf alle Fälle manu­ell nach­ho­len und anschlie­ßend das ent­spre­chende Pass­wort ändern.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://www.outbank.de/outbank-os-x-mac-sicherheitshinweis-zu-version-2–0-0/
http://www.heise.de/mac-and-i/meldung/Outbank-2-mit-Passwort-Leck-1786837.html

Manch­mal sind es die bana­len Pro­bleme, wel­chen einen in den Wahn­sinn trei­ben. So zum Bei­spiel wenn auf einem iOS Gerät ein WLAN ein­ge­rich­tet ist und die­ses mit einem fal­schen Pass­wort ver­se­hen wurde. Das kann dann pas­sie­ren wenn man das Pass­wort des WLANs ändert oder auf dem Gerät bei der Ein­rich­tung ein fal­sches Pass­wort ein­ge­ben hat.

Der WLAN Auswahldialog

Dies führt nun dazu das dass ent­spre­chende Gerät immer wie­der ver­sucht sich mit der WLAN Gegen­stelle zu ver­bin­den, ohne das eine Ver­bin­dung zu Stande kommt. Ein neues Pass­wor­t­ein­ga­be­feld bekommt man nicht ange­bo­ten. Damit dies wie­der geschieht geht man in die Ein­stel­lun­gen zu den WLAN Ein­stel­lun­gen und drückt dort auf den blauen Pfeil rechts beim ent­spre­chen­den WLAN.

Die Ein­stel­lung für ein bestimm­tes WLAN

Dort betä­tigt man den But­ton „Die­ses Netz­werk igno­rie­ren“ und anschlie­ßend kann man sich wie­der zu dem Netz­werk ver­bin­den und wird auch nach einem Pass­wort gefragt, so das man in der Lage ist, wie­der erfolg­reich eine Ver­bin­dung zur Gegen­stel­len auf­bauen zu können.

Das alte Inver­tika Forum wurde vor eini­gen Tagen ja in das Haupt­sys­tem inte­griert, damit man nun alles mit einem Account nut­zen kann. Bestands­nut­zer müs­sen aller­dings vor dem ers­ten Mal ein­log­gen die „Pass­wort ver­ges­sen?“ Funk­tion benutzen.

Anschlie­ßend bekommt der Nut­zer sein neues Pass­wort zuge­schickt mit wel­chem er sich dann pro­blem­los ein­log­gen kann.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://invertika.org

Unter Umstän­den kann es pas­sie­ren das man das Pass­wort für seine Post­greSQL Daten­bank ver­gisst. Wenn man aller­dings Kon­trolle über den Ser­ver hat, ist dies kein Pro­blem. Um das Pass­wort neu zu set­zen muss man im ers­ten Schritt die pg_hba.conf Datei bearbeiten:

# IPv4 local connections:
 host    all             all             127.0.0.1/32            md5
 # IPv6 local connections:
 #host    all             all             ::1/128                 md5

wird dabei zu:

# IPv4 local connections:
 host    all             all             127.0.0.1/32            trust
 # IPv6 local connections:
 #host    all             all             ::1/128                 trust

geän­dert. Nach­dem die Kon­fi­gu­ra­tion neu gela­den wurde, kann man sich mit einem x-beliebigen Pass­wort anmel­den und ein neues Pass­wort set­zen. Anschlie­ßend setzt man die pg_hba.conf wie­der zurück und lädt die Kon­fi­gu­ra­tion aber­mals neu.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://de.wikipedia.org/wiki/Postgresql

Möchte man in der Domaine die Pass­wort­richt­li­nie ändern (z.B. die mini­male Länge der Pass­wör­ter) so loggt man sich auf sei­nem Domä­nen­ser­ver ein und geht dort in die Ver­wal­tung (Ein­stel­lun­gen -> Sys­tem­steue­rung -> Ver­wal­tung). Dort wählt man dann Active Direc­tory Benut­zer und Com­pu­ter aus und klickt dann mit der rech­ten Maus­taste auf den Domä­nen­na­men und dort auf Eigenschaften.

In dem sich öff­nen­den Dia­log wählt man dann den Tab Grup­pen­richt­li­nie. Nun kann man ent­we­der eine neue anle­gen oder die beste­hende modi­fi­zie­ren. Wobei Micro­soft emp­fiehlt eine neue anzu­le­gen, diese kann näm­lich schnell deak­ti­viert wer­den falls doch etwas schief gehen sollte und so schnell durch die Stan­dard­richt­li­nie ersetzen.

Nach­dem man die Richt­li­nie geöff­net hat, kann man unter Windows-Einstellungen -> Sicher­heits­ein­stel­lun­gen -> Kon­to­richt­li­nien -> Kenn­wort­richt­li­nie alles nach sei­nen Wün­schen modifizieren.